Found 2 records.

Status: Reported (2)

RFC 7591, "OAuth 2.0 Dynamic Client Registration Protocol", July 2015

Errata ID: 7782
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Würtele
Date Reported: 2024-01-25

Section 3.2.1 says:

client_id
      REQUIRED.  OAuth 2.0 client identifier string.  It SHOULD NOT be
      currently valid for any other registered client, though an
      authorization server MAY issue the same client identifier to
      multiple instances of a registered client at its discretion.

It should say:

client_id
      REQUIRED.  OAuth 2.0 client identifier string.  It MUST NOT be
      currently valid for any other registered client, though an
      authorization server MAY issue the same client identifier to
      multiple instances of a registered client at its discretion.

Notes:

Allowing the same client_id for multiple clients is a contradiction to:

1. This document, Section 1.3, (D), 2nd bullet point: "a client identifier that is unique at the server"

2. This document, Section 3.1: "The authorization server assigns this client a unique client identifier"

3. (normative reference) RFC 6749, Section 2.2: "The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client. [...] The client identifier is unique to the authorization server."

4. (non-normative reference) OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2, Section 2: "Clients have metadata associated with their unique Client Identifier at the Authorization Server."; Section 3.1: "The Authorization Server assigns this Client a unique Client Identifier"; Section 3.2: "client_id REQUIRED. Unique Client Identifier. It MUST NOT be currently valid for any other registered Client. "

Errata ID: 7969
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ivan Mok
Date Reported: 2024-06-03

Section 2.3 says:

   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

It should say:

   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.

Report New Errata