This errata seems to be correct, an omission in the example that doesn't align with the normative requirements. ________________________________ From: RFC Errata System <rfc-edi...@rfc-editor.org> Sent: Monday, June 3, 2024 1:30 PM To: i...@justin.richer.org <i...@justin.richer.org>; m...@microsoft.com <m...@microsoft.com>; ve7...@ve7jtb.com <ve7...@ve7jtb.com>; maciej.machu...@gmail.com <maciej.machu...@gmail.com>; phil.h...@yahoo.com <phil.h...@yahoo.com>; debcool...@gmail.com <debcool...@gmail.com>; paul.wout...@aiven.io <paul.wout...@aiven.io>; hannes.tschofe...@arm.com <hannes.tschofe...@arm.com>; rifaat.s.i...@gmail.com <rifaat.s.i...@gmail.com> Cc: i...@pingidentity.com <i...@pingidentity.com>; oauth@ietf.org <oauth@ietf.org>; rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> Subject: [OAUTH-WG] [Technical Errata Reported] RFC7591 (7969)
The following errata report has been submitted for RFC7591, "OAuth 2.0 Dynamic Client Registration Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7969 -------------------------------------- Type: Technical Reported by: Ivan Mok <i...@pingidentity.com> Section: 2.3 Original Text ------------- For example, a software statement could contain the following claims: { "software_id": "4NRB1-0XZABZI9E6-5SM3R", "client_name": "Example Statement-based Client", "client_uri": "https://client.example.net/"; } The following non-normative example JWT includes these claims and has been asymmetrically signed using "RS256" (with line breaks for display purposes only): eyJhbGciOiJSUzI1NiJ9. eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ. GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA Corrected Text -------------- For example, a software statement could contain the following claims: { "iss": "https://example.com";, "software_id": "4NRB1-0XZABZI9E6-5SM3R", "client_name": "Example Statement-based Client", "client_uri": "https://client.example.net/"; } The following non-normative example JWT includes these claims and has been asymmetrically signed using "RS256" (with line breaks for display purposes only): eyJhbGciOiJSUzI1NiJ9.<updatedPayloadWithIss>.<updatedSignature> Notes ----- Section 2.3 Software Statement says, "the software statement ... MUST contain an "iss" (issuer) claim denoting the party attesting to the claims in the software statement." It would be useful to readers if the sample software statement in the same section adheres to this condition. If this change is reasonable, the signed JWT in section 3.1.1. Client Registration Request Using a Software Statement should also be updated. Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- RFC7591 (draft-ietf-oauth-dyn-reg-30) -------------------------------------- Title : OAuth 2.0 Dynamic Client Registration Protocol Publication Date : July 2015 Author(s) : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt Category : PROPOSED STANDARD Source : Web Authorization Protocol Stream : IETF Verifying Party : IESG _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
