[Openid-specs-ab] Interaction between OIDC Registration and RFC7591

Justin Richer 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?

  -- Justin


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.
>
> Thanks,
> George
>
> 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.
>>
>> Phil
>>
>> 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 
>>> requests?
>>>
>>> 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>> 
>>>> wrote:
>>>>
>>>> The server is certainly right to ignore a scope request that it 
>>>> doesn’t understand, per this language 
>>>> athttps://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse:
>>>> An Authorization Server MAY ignore values provided by the client, 
>>>> and MUST ignore any fields sent by the Client that it does not 
>>>> understand.
>>>> From an RFC 7591, the server’s behavior seems fine to me too. 
>>>> https://tools.ietf.org/html/rfc7591#section-2says:
>>>>    The implementation and use of all client metadata fields is 
>>>> OPTIONAL, unless stated otherwise.
>>>> Likewise, it also adds:
>>>>    The
>>>>    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 
>>>> <https://tools.ietf.org/html/rfc7591#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
>>>> *From:*Openid-specs-ab 
>>>> [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
>>>>     again.
>>>>     Phil
>>>>     @independentid
>>>>     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
>>>>         interoperability.
>>>>
>>>>         -- Justin
>>>>
>>>>         _______________________________________________
>>>>         Openid-specs-ab mailing list
>>>>         Openid-specs-ab at lists.openid.net
>>>>         <mailto:Openid-specs-ab at lists.openid.net>
>>>>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20161014/0bbda577/attachment.html>

More information about the Openid-specs-ab mailing list