Committed to connecting the world

  •  

ITU-T work programme

Home : ITU-T Home : ITU-T Work Programme : X.2312     
  ITU-T A.5 justification information for referenced document IETF RFC 8252  in draft X.2312
1. Clear description of the referenced document:
Name: IETF RFC 8252
Title: RFC 8252: OAuth 2.0 for Native Apps, IETF, October 2017
2. Status of approval:
RFC 8252 was published as an IETF Best Current Practice (BCP 212) in October 2017. Finalized IETF document.
3. Justification for the specific reference:
RFC 8252 defines OAuth 2.0 best practices for native applications, including the use of loopback interface redirection as a redirect URI mechanism. X.f2sp Section 7.3.2.2 contains a shall requirement that prohibits HTTP redirect URIs "except for native clients that use loopback interface Redirection as described in Section 7.3 of [RFC8252]." This exception is normatively conditioned on RFC 8252. Incorporation of the full text is inappropriate as only the loopback redirection 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 October 2017 (BCP 212). Widely referenced in OAuth 2.0 native app implementations. Freely available at https://www.rfc-editor.org/rfc/rfc8252.
6. The degree of stability or maturity of the document:
Finalized IETF Best Current Practice (BCP). Stable since October 2017.
7. Relationship with other existing or emerging documents:
Referenced by the OAuth 2.0 Security BCP (RFC 9700) and by multiple OAuth 2.0 profiles for native application security guidance. No ITU-T/ISO/IEC equivalent.
8. Any explicit references within that referenced document should also be listed:
Normative references within RFC 8252: RFC 2119, RFC 3986, RFC 6749, RFC 6819. 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):
Note: This form is based on Recommendation ITU-T A.5