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 <[email protected]>
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 <[email protected]> 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 <
>> [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
>>
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
