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

Justin Richer jricher at mit.edu
Thu Oct 13 17:28:09 UTC 2016


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> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20161013/077e2871/attachment.html>


More information about the Openid-specs-ab mailing list