Tq you for assistance and remind me. On Sat, 27 Jan 2024, 04:01 , <oauth-requ...@ietf.org> wrote:
> Send OAuth mailing list submissions to > oauth@ietf.org > > 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 > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > 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 <jric...@mit.edu> > To: RFC Errata System <rfc-edi...@rfc-editor.org> > Cc: "m...@microsoft.com" <m...@microsoft.com>, John Bradley > <ve7...@ve7jtb.com>, "maciej.machu...@gmail.com" > <maciej.machu...@gmail.com>, "phil.h...@yahoo.com" > <phil.h...@yahoo.com>, "r...@cert.org" <r...@cert.org>, Paul Wouters > <paul.wout...@aiven.io>, "hannes.tschofe...@arm.com" > <hannes.tschofe...@arm.com>, Rifaat Shekh-Yusef > <rifaat.s.i...@gmail.com>, "tim.wuert...@sec.uni-stuttgart.de" > <tim.wuert...@sec.uni-stuttgart.de>, oauth <oauth@ietf.org> > Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7591 (7782) > Message-ID: <03509899-8415-4843-afc0-bc14248d9...@mit.edu> > 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 < > 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 > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 183, Issue 59 > ************************************** >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
