|
1.
|
Clear description of the referenced document:
|
|
|
|
Name:
|
IETF RFC 9207
|
|
Title:
|
RFC 9207: OAuth 2.0 Authorization Server Issuer Identification, IETF, March 2022
|
|
|
2.
|
Status of approval:
|
|
|
RFC 9207 was published as an IETF Proposed Standard in March 2022. Finalized IETF document.
|
|
3.
|
Justification for the specific reference:
|
|
|
RFC 9207 defines the iss (issuer) parameter in the OAuth 2.0 authorization response, which prevents mix-up attacks where a client could be confused about which authorization server responded. X.f2sp mandates this as a shall requirement for authorization servers (Section 7.3.2.2: "shall return an iss parameter in the authorization response according to [RFC9207]") and clients (Section 7.3.3.2: "shall check the iss parameter in the authorization response according to [RFC9207] to prevent mix-up attacks"). Incorporation of the full text is inappropriate as only the iss parameter mechanism is referenced. Freely available. No ITU-T or ISO/IEC equivalent.
|
|
4.
|
Current information, if any, about IPR issues:
|
|
|
No known patent claims. Freely available.
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
Published March 2022. Implemented in modern OAuth 2.0 authorization servers and clients. Freely available at https://www.rfc-editor.org/rfc/rfc9207.
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
Stable, finalized IETF Proposed Standard. Not revised since March 2022.
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
Addresses mix-up attacks identified in the OAuth 2.0 Security BCP (RFC 9700). Specifically required by FAPI 2.0. No ITU-T/ISO/IEC equivalent.
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
Normative references within RFC 9207: RFC 2119, RFC 3986, RFC 6749, 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):
|
|
|
|
