Tq you for assistance and remind me. On Sat, 27 Jan 2024, 04:01 , <[email protected]> wrote:
> Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: [Technical Errata Reported] RFC7591 (7782) (Justin Richer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 26 Jan 2024 18:42:27 +0000 > From: Justin Richer <[email protected]> > To: RFC Errata System <[email protected]> > Cc: "[email protected]" <[email protected]>, John Bradley > <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]>, Paul Wouters > <[email protected]>, "[email protected]" > <[email protected]>, Rifaat Shekh-Yusef > <[email protected]>, "[email protected]" > <[email protected]>, oauth <[email protected]> > Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7591 (7782) > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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 < > [email protected]> 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 <[email protected]> > > > > 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 > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 183, Issue 59 > ************************************** >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
