I feel like the source of the confusion might be, *what is the purpose of the statement in the description of this property. e.g. *Why say anything at all?
If the description was: OAuth 2.0 client identifier string. An authorization server MAY issue the same client identifier to multiple instances of a registered client at its discretion. Or even: OAuth 2.0 client identifier string. What was the purpose of this statement in the first place. For context 3.2.1. is the *Client Information Response* OAuth 2.0 client identifier string. An authorization server MAY issue the > same client identifier to multiple instances of a registered client at its > discretion. This version is great because it is consistent with the information provided elsewhere in the RFC regarding instances, and reusing the client_id, if the AS desires. But this part: *It SHOULD NOT be currently valid for any other registered client*, seems like it just exists to create confusion. Was there an actual concern that this statement was created to help implementations avoid? On Fri, Jan 26, 2024 at 10:15 PM Tom Jones <thomasclinganjo...@gmail.com> wrote: > The whole thing is pointless as the client owner (as opposed to the > subject for which client status is requested) can just define the instances > to be the same. There can be no way to attest to the validity of such an > assertion. > > thx ..Tom (mobile) > > On Fri, Jan 26, 2024, 10:42 AM Justin Richer <jric...@mit.edu> wrote: > >> I believe this correction is valid, though I think that the changing of a >> normative requirement is beyond an erratum. >> >> Ultimately, though, this comes down to the definition of what "a client" >> is, which is pretty fuzzy in OAuth. The AS needs to be able to issue the >> same identifier to what it feels is an instance of the same client >> software, if it wants to do that. You can think of these instances as >> different clients in a way, which is what the ’SHOULD NOT’ was for. >> However, if you contend that these instances are "the same client" then the >> 'MUST NOT' makes sense. >> >> In the end, I’m not sure how much difference this change would actually >> make for implementations, because of the fuzziness around the definitions. >> I’m hopeful that some of the new language in OAuth 2.1 around client types >> and instances and registration will help settle this and we can call things >> something consistent. >> >> As such, I’m on the fence whether we should accept or reject the erratum >> — >> >> - if we accept, that’s a normative change, but not likely to affect >> other implementations (especially those that implement the OIDC version >> already) >> - if we reject, we obviously don’t change implementations but we also >> keep carrying this ambiguity forward >> >> — Justin >> >> > On Jan 25, 2024, at 1:25 AM, RFC Errata System < >> rfc-edi...@rfc-editor.org> wrote: >> > >> > 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/eid7782 >> > >> > -------------------------------------- >> > Type: Technical >> > Reported by: Tim Würtele <tim.wuert...@sec.uni-stuttgart.de> >> > >> > Section: 3.2.1 >> > >> > Original Text >> > ------------- >> > 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. >> > >> > Corrected Text >> > -------------- >> > 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. >> " >> > >> > 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 >> > Area : Security >> > Stream : IETF >> > Verifying Party : IESG >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth