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

Sergey Beryozkin sberyozkin at gmail.com
Wed Oct 19 08:53:08 UTC 2016


Hi

In our initial implementation we do code the OIDC client registration 
service as the extension of the Oauth2 centric RFC 7591 service 
implementation, though a number of properties which may need to be 
treated differently in two services are not covered yet...
Same for the the OIDC vs OAuth2 discovery/metadata services...
Thanks, Sergey
On 19/10/16 06:49, Torsten Lodderstedt via Openid-specs-ab wrote:
> Hi all,
>
> beside the specific problems regarding "scope", I think the general
> issue is the OIDC registration spec is NOT an extension of RFC 7591.
> This means, as already pointed out by Justin, software statements
> (specwise) simply do not exist in the OpenID Connect universe.
>
> In order to leverage software statements in MODRNA, we therefore needed
> to write another registration spec, which combines elements of RFC 7591
> and OIDC client registration
> (http://openid.net/wordpress-content/uploads/2014/04/draft-mobile-registration-01.html).
> I consider this an interims solution (at best) and I hope we will find a
> solution, which works for OIDC in general.
>
> To me the obvious solution is to update the OIDC Client Registration
> spec to become an extension of RFC 7591.
>
> What do you guys think?
>
> best regards,
> Torsten.
>
> Am 15.10.2016 um 11:11 schrieb Roland Hedberg via Openid-specs-ab
> <openid-specs-ab at lists.openid.net
> <mailto:openid-specs-ab at lists.openid.net>>:
>
>> Since the spec says:
>> ’An Authorization Server MAY ignore values provided by the client, and
>> MUST ignore any fields sent by the Client that it does not understand.’
>>
>> I am with George in that the client should assume that the AS ignored
>> the scope request since scope is
>> not in the listed set of parameters for dynamic client registration.
>>
>>> 15 okt. 2016 kl. 04:31 skrev George Fletcher via Openid-specs-ab
>>> <openid-specs-ab at lists.openid.net
>>> <mailto:openid-specs-ab at lists.openid.net>>:
>>>
>>> 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 at
>>>>>>>> https://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-2 says:
>>>>>>>>   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 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
>>>>>>>>
>>>>>>>> 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
>>>>>> <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
>>> <mailto:Openid-specs-ab at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>> -- Roland
>> "Education is the path from cocky ignorance to miserable uncertainty.”
>> - Mark Twain
>>
>>
>>
>> _______________________________________________
>> 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
>



More information about the Openid-specs-ab mailing list