|
1.
|
Clear description of the referenced document:
|
|
|
|
Name:
|
IETF RFC 9126
|
|
Title:
|
RFC 9126: OAuth 2.0 Pushed Authorization Requests, IETF, September 2021
|
|
|
2.
|
Status of approval:
|
|
|
RFC 9126 was published as an IETF Proposed Standard in September 2021. Finalized IETF document.
|
|
3.
|
Justification for the specific reference:
|
|
|
RFC 9126 defines Pushed Authorization Requests (PAR), a mechanism whereby clients push authorization request parameters directly to the authorization server before redirecting the user agent. X.f2sp mandates PAR as a shall requirement for both authorization servers (Section 7.3.2.2: "shall support client-authenticated pushed authorization requests according to [RFC9126]"; "shall reject authorization requests sent without [RFC9126]") and clients (Section 7.3.3.2: "shall use pushed authorization requests according to [RFC9126]"). PAR is one of the core security mechanisms of the FAPI 2.0 profile. Incorporation of the full text is inappropriate as PAR is an extension to RFC 6749 already referenced. Freely available. No ITU-T or ISO/IEC equivalent.
|
|
4.
|
Current information, if any, about IPR issues:
|
|
|
No known patent claims. IETF IPR database lists no relevant patents. Freely available.
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
Published September 2021. Deployed in financial-grade API ecosystems globally. Freely available at https://www.rfc-editor.org/rfc/rfc9126.
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
Stable, finalized IETF Proposed Standard. Not revised since September 2021.
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
Core security mechanism referenced alongside PKCE (RFC 7636) and DPoP (RFC 9449) in the FAPI 2.0 profile. No ITU-T/ISO/IEC equivalent.
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
Normative references within RFC 9126: RFC 2119, RFC 3986, RFC 6749, RFC 7159, RFC 7519, RFC 8174, RFC 8414. All IETF documents; IETF is qualified under Annex B.
|
|
9.
|
Qualification of
ISOC/IETF:
|
|
|
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).
9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.
9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
|
|
10.
|
Other (for any supplementary information):
|
|
|
|
