Read the pushed form and its response
02A UTF-8 form carries authorization parameters; a successful JSON response gives the bound reference and its lifetime.
The response binds the example URI to picnic-app with a 60-second lifetime. This is stored request data, not a token or proof of user approval.
Source for this drawing: RFC 9126 · Read RFC section 2.1 ↗
New to this? Start hereA quick picture + helpful background
A key is different from permission.
An app, a person, and a server have different roles. Follow who asks, who grants permission, and who checks the credential. A key in the drawing is an analogy, not a literal protocol field.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The pushed request body is an authorization request, not a token request.
- The client uses POST with application/x-www-form-urlencoded and UTF-8. client_id is required; applicable client-authentication parameters serve authentication only. request_uri MUST NOT be supplied to the PAR endpoint.
- This public-client example uses PKCE (Proof Key for Code Exchange) with S256 and a state value. The verifier stays with the client; only its derived challenge goes into the authorization request. Later RFC9700 §2.1.1 requires PKCE for public code-flow clients.
- After successful verification, the server MUST generate a request URI and return HTTP 201 with JSON request_uri and expires_in. expires_in is a positive integer number of seconds; 60 here is an example, not a mandated lifetime.
- The URI MUST bind to the pushing client and include a cryptographically strong unpredictable part. The fixed teaching URI is deliberately not a production random value; referenced entropy guidance is in RFC9101 §10.2(d).
All identifiers, state values and code verifiers shown are public teaching fixtures. Real requests need fresh transaction binding and unpredictable references. Selected headers/fields are illustrated, not a complete HTTP message with framing. Example supports public clients without authentication credentials, as permitted by OAuth client-type rules.
Read the RFC section ↗