[Openid-specs-ab] Interaction between OIDC Registration and RFC7591
jricher at mit.edu
Sat Oct 15 02:13:37 UTC 2016
Which is exactly the crux of my question: what does a well-behaved
client do in this situation? It asked for a value from the server, the
server didn't return an error but gave back *nothing* in that field --
does the client substitute its original requested values or does it
ignore its requested values? What are the implications (for security and
functionality) of doing this?
On 10/13/2016 7:17 PM, George Fletcher wrote:
> Isn't the issue that the client doesn't have any clue (i.e. way to
> tell) as to whether the server simply ignored the sent value or
> explicitly rejected it as both are allowed behaviors of the AS. In
> this case I agree with Phil, that really all the client can do is try
> again and deal with rejection (or not) on an individual request basis.
> In general, this ambiguous behavior does make it difficult to write
> well behaved clients, and seems like something that should be
> addressed going forward.
> On 10/13/16 5:00 PM, Phil Hunt (IDM) via Openid-specs-ab wrote:
>> The registration response is simply undefined. The client cannot
>> infer any meaning by an absence.
>> I would expect the client to retry during the authz step. It can
>> always be refused again.
>> On Oct 13, 2016, at 4:54 PM, Justin Richer <jricher at mit.edu
>> <mailto:jricher at mit.edu>> wrote:
>>> Right, the client’s not treating the server’s response as an error,
>>> and the client does in fact proceed — by assuming that there is *no*
>>> scope value to be sent in the later requests. The server doesn’t
>>> allow a blank or defaulted scope value in the authorization request,
>>> which makes subsequent connections fail. Should a server that
>>> doesn’t allow registration of scope values also disallow blank scope
>>> What should be the guidance for client developers who get back a
>>> null or empty value that they expect or want to be there? I don’t
>>> think it’s right to special-case the “scope” parameter here, so I’m
>>> after general behavior guidance that can be applied to the entire
>>> client data model. My interpretation has always been that the client
>>> requests and the server dictates the registration model, and the
>>> client reacts to that dictated model. The question is now what is
>>> the proper reaction?
>>> — Justin
>>>> On Oct 13, 2016, at 2:43 PM, Mike Jones
>>>> <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>>
>>>> The server is certainly right to ignore a scope request that it
>>>> doesn’t understand, per this language
>>>> An Authorization Server MAY ignore values provided by the client,
>>>> and MUST ignore any fields sent by the Client that it does not
>>>> From an RFC 7591, the server’s behavior seems fine to me too.
>>>> The implementation and use of all client metadata fields is
>>>> OPTIONAL, unless stated otherwise.
>>>> Likewise, it also adds:
>>>> authorization server MUST ignore any client metadata sent by the
>>>> client that it does not understand (for instance, by silently
>>>> removing unknown metadata from the client's registration record
>>>> during processing). The authorization server MAY reject any
>>>> requested client metadata values by replacing requested values with
>>>> suitable defaults as described in Section 3.2.1
>>>> <https://tools.ietf.org/html/rfc7591#section-3.2.1> or by returning an
>>>> error response as described in Section 3.2.2
>>>> Therefore, the RP can’t expect that either OpenID Connect Dynamic
>>>> Registration implementations or RFC 7591 implementations will
>>>> process any “scope” requests. In either case, the RP needs to be
>>>> prepared to proceed without server support for this optional RFC
>>>> 7591 feature.
>>>> -- Mike
>>>> [mailto:openid-specs-ab-bounces at lists.openid.net]*On Behalf
>>>> Of*Justin Richer via Openid-specs-ab
>>>> *Sent:*Thursday, October 13, 2016 1:28 PM
>>>> *To:*Phil Hunt <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>>
>>>> *Cc:*openid-specs-ab at lists.openid.net
>>>> <mailto:openid-specs-ab at lists.openid.net> Ab
>>>> <openid-specs-ab at lists.openid.net
>>>> <mailto:openid-specs-ab at lists.openid.net>>
>>>> *Subject:*Re: [Openid-specs-ab] Interaction between OIDC
>>>> Registration and RFC7591
>>>> I agree that a default scope should be allowed, but the server
>>>> implementation in question requires all clients to send scopes at
>>>> all times. This confuses our client code, which depends on the
>>>> registration response to figure out which scopes it’s allowed to
>>>> use. I suppose we could special-case this but it feels odd for the
>>>> client to effectively override an AS decision.
>>>> — Justin
>>>> On Oct 13, 2016, at 10:49 AM, Phil Hunt <phil.hunt at oracle.com
>>>> <mailto:phil.hunt at oracle.com>> wrote:
>>>> From a strict read of the specs, I would infer the opposite
>>>> logic. If the scope *was* accepted a registration, that means
>>>> the client does *not* need to provide it at authorization time
>>>> as it becomes the default.
>>>> If scope was not accepted, it simply means defaulting not
>>>> supported and the client should authorize as normal.
>>>> Even if you disagree on this, the client should always be able
>>>> to specify a scope regardless - the AS is always free to reject
>>>> www.independentid.com <http://www.independentid.com/>
>>>> phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
>>>> On Oct 13, 2016, at 7:51 AM, Justin Richer via
>>>> Openid-specs-ab <openid-specs-ab at lists.openid.net
>>>> <mailto:openid-specs-ab at lists.openid.net>> wrote:
>>>> We've come across an interesting interaction between
>>>> related specs.
>>>> Our client software requests a "scope" value as part of its
>>>> client metadata, as defined in RFC7591. The OIDC
>>>> Registration spec does not define this metadata value, but
>>>> of course allows it as an extension. Our server accepts
>>>> this value as well.
>>>> We're testing against a server implementation that ignores
>>>> the incoming "scope" metadata request entirely, since it's
>>>> not explicitly listed in the OIDC Registration
>>>> specification. Part of this ignoring process is that the
>>>> server returns a registration object back to the client
>>>> that omits the "scope" value. Our client, following the
>>>> advice in RFC7591 and the OIDC Registration spec both,
>>>> takes this response from the server to mean that it doesn't
>>>> have a registered scope set with the server. This
>>>> consequently causes our client to not send a "scope" value
>>>> in the authorization request, which causes the server to
>>>> fail because the "scope" is required.
>>>> I think the right solution to this is to revise the OIDC
>>>> Registration specification to be a normative extension of
>>>> RFC7591/RFC7592, as has been discussed previously on this
>>>> list and, to my recollection, generally agreed on but not
>>>> acted on yet. Software statements and other enhancements
>>>> that are in RFC7591 would also be available as options
>>>> without further effort.
>>>> In practice, most implementations that I've seen already
>>>> mix the two specifications. This is the intended effect of
>>>> having wire compatibility, of course. Changing the spec
>>>> would align it better with reality, and help avoid cases
>>>> like this one where strict interpretation leads to lack of
>>>> -- Justin
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> <mailto:Openid-specs-ab at lists.openid.net>
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab