|
1.
|
Clear description of the referenced document:
|
|
|
|
Name:
|
IETF RFC 9449
|
|
Title:
|
RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP), IETF, September 2023
|
|
|
2.
|
Status of approval:
|
|
|
RFC 9449 was published as an IETF Proposed Standard in September 2023. Finalized IETF document.
|
|
3.
|
Justification for the specific reference:
|
|
|
RFC 9449 defines DPoP (Demonstrating Proof of Possession), an application-level sender-constraining mechanism for OAuth 2.0 access tokens using a proof-of-possession JWT. X.f2sp mandates DPoP as one of two required mechanisms for sender-constraining (shall requirement, Sections 7.3.2.1 and 7.3.3.1), and further requires "Authorization Code Binding to DPoP Key" as defined in Section 10.1 of RFC 9449 (Section 7.3.2.1). DPoP is one of the two core sender-constraining mechanisms of the FAPI 2.0 profile. Incorporation of the full text is inappropriate as DPoP is an extension to RFC 6749. 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 2023. Increasingly deployed as an alternative to MTLS sender-constraining in cloud and mobile OAuth 2.0 deployments. Freely available at https://www.rfc-editor.org/rfc/rfc9449.
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
Stable, finalized IETF Proposed Standard. Not revised since September 2023.
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
One of the two sender-constraining mechanisms defined in X.f2sp (alongside RFC 8705/MTLS). Referenced by the OAuth 2.0 Security BCP (RFC 9700). No ITU-T/ISO/IEC equivalent.
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
Normative references within RFC 9449: RFC 2119, RFC 3986, RFC 6749, RFC 7517, RFC 7518, RFC 7519, RFC 7800, RFC 8174, RFC 8446, RFC 9110. 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):
|
|
|
|
