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

Sat Oct 15 02:31:26 UTC 2016

Given the current situation, I think the client should assume the AS 
ignored the values (rather than rejected them) and effectively "try 
again" on the request. At least with scope value, I don't see any 
security risk and if the AS doesn't support those scope values, that 
should be clear in the token response.

In general, for clients, I prefer to always be explicit with requested 
scopes rather than relying on a pre-registered default scope set.

Thanks,
George

On 10/14/16 10:13 PM, Justin Richer wrote:
>
> 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/dc5e3182/attachment.html>