<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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? <div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class=""> — Justin</div><div class=""><br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 13, 2016, at 2:43 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" class="">Michael.Jones@microsoft.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" class="">The server is certainly right to ignore a scope request that it doesn’t understand, per this language at<span class="Apple-converted-space"> </span><a href="https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse" style="color: purple; text-decoration: underline;" class="">https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse</a>:<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span lang="EN" style="font-family: Verdana, sans-serif;" class="">An Authorization Server MAY ignore values provided by the client, and MUST ignore any fields sent by the Client that it does not understand.</span><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" class="">From an RFC 7591, the server’s behavior seems fine to me too. <span class="Apple-converted-space"> </span><a href="https://tools.ietf.org/html/rfc7591#section-2" style="color: purple; text-decoration: underline;" class="">https://tools.ietf.org/html/rfc7591#section-2</a><span class="Apple-converted-space"> </span>says:<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; page-break-before: always;" class=""><span lang="EN" style="font-family: 'Courier New';" class=""> The implementation and use of all client metadata fields is OPTIONAL, unless stated otherwise.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" class="">Likewise, it also adds:<o:p class=""></o:p></span></div><pre style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Courier New'; page-break-before: always;" class=""><span lang="EN" class=""> The<o:p class=""></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Courier New'; page-break-before: always;" class=""><span lang="EN" class=""> authorization server MUST ignore any client metadata sent by the<o:p class=""></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Courier New'; page-break-before: always;" class=""><span lang="EN" class=""> client that it does not understand (for instance, by silently<o:p class=""></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Courier New'; page-break-before: always;" class=""><span lang="EN" class=""> removing unknown metadata from the client's registration record<o:p class=""></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Courier New'; page-break-before: always;" class=""><span lang="EN" class=""> during processing). The authorization server MAY reject any<o:p class=""></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Courier New'; page-break-before: always;" class=""><span lang="EN" class=""> requested client metadata values by replacing requested values with<o:p class=""></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Courier New'; page-break-before: always;" class=""><span lang="EN" class=""> suitable defaults as described in <a href="https://tools.ietf.org/html/rfc7591#section-3.2.1" style="color: purple; text-decoration: underline;" class="">Section 3.2.1</a> or by returning an<o:p class=""></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Courier New'; page-break-before: always;" class=""><span lang="EN" class=""> error response as described in <a href="https://tools.ietf.org/html/rfc7591#section-3.2.2" style="color: purple; text-decoration: underline;" class="">Section 3.2.2</a>.<o:p class=""></o:p></span></pre><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" class="">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.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" class=""> -- Mike<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><a name="_MailEndCompose" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" class=""><o:p class=""> </o:p></span></a></div><span class=""></span><div class=""><div style="border-style: solid none none; border-top-color: rgb(225, 225, 225); border-top-width: 1pt; padding: 3pt 0in 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><b class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif;" class="">From:</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="Apple-converted-space"> </span>Openid-specs-ab [<a href="mailto:openid-specs-ab-bounces@lists.openid.net" class="">mailto:openid-specs-ab-bounces@lists.openid.net</a>]<span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>Justin Richer via Openid-specs-ab<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Thursday, October 13, 2016 1:28 PM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Phil Hunt <<a href="mailto:phil.hunt@oracle.com" class="">phil.hunt@oracle.com</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span><a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a> Ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [Openid-specs-ab] Interaction between OIDC Registration and RFC7591<o:p class=""></o:p></span></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">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. <o:p class=""></o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""> — Justin<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">On Oct 13, 2016, at 10:49 AM, Phil Hunt <<a href="mailto:phil.hunt@oracle.com" style="color: purple; text-decoration: underline;" class="">phil.hunt@oracle.com</a>> wrote:<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">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.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">If scope was not accepted, it simply means defaulting not supported and the client should authorize as normal. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">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.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">Phil<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">@independentid<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><a href="http://www.independentid.com/" style="color: purple; text-decoration: underline;" class="">www.independentid.com</a><o:p class=""></o:p></div></div></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><a href="mailto:phil.hunt@oracle.com" style="color: purple; text-decoration: underline;" class="">phil.hunt@oracle.com</a><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><o:p class=""> </o:p></p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">On Oct 13, 2016, at 7:51 AM, Justin Richer via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" style="color: purple; text-decoration: underline;" class="">openid-specs-ab@lists.openid.net</a>> wrote:<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">We've come across an interesting interaction between related specs.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">-- Justin<br class=""><br class="">_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" style="color: purple; text-decoration: underline;" class="">Openid-specs-ab@lists.openid.net</a><br class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" style="color: purple; text-decoration: underline;" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></div></div></body></html>