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
