<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I was never happy with 7591, it wasn't widely used. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">However I don't see why a profile of 7591 can't dictate expected behavior for unsupported vs unknown vs defaulted metadata. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Profiling use of statements may also be useful. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">There is tremendous resistance to adding yet another protocol. </div><div id="AppleMailSignature"><br>Phil</div><div><br>On Oct 19, 2016, at 8:48 AM, Justin Richer via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">+1 to everything Torsten has said.<div class=""><br class=""></div><div class="">Plus, since the group decided to carve out registration separately from the core OIDC protocol, we can rev that spec separately from the rest of the work.</div><div class=""><br class=""></div><div class=""> — Justin</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 18, 2016, at 10:49 PM, Torsten Lodderstedt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class=""></div><div class="">Hi all,</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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 (<a href="http://openid.net/wordpress-content/uploads/2014/04/draft-mobile-registration-01.html" class="">http://openid.net/wordpress-content/uploads/2014/04/draft-mobile-registration-01.html</a>). I consider this an interims solution (at best) and I hope we will find a solution, which works for OIDC in general.</div><div class=""><br class=""></div><div class="">To me the obvious solution is to update the OIDC Client Registration spec to become an extension of RFC 7591.</div><div class=""><br class=""></div><div class="">What do you guys think?</div><div class=""><br class=""></div><div class="">best regards,</div><div class="">Torsten.</div><div class=""><br class="">Am 15.10.2016 um 11:11 schrieb Roland Hedberg via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="">Since the spec says:</span><br class=""><span 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><br class=""><span class=""></span><br class=""><span class="">I am with George in that the client should assume that the AS ignored the scope request since scope is</span><br class=""><span class="">not in the listed set of parameters for dynamic client registration.</span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">15 okt. 2016 kl. 04:31 skrev George Fletcher via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>>:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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. </span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">In general, for clients, I prefer to always be explicit with requested scopes rather than relying on a pre-registered default scope set.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Thanks,</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">George</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">On 10/14/16 10:13 PM, Justin Richer wrote:</span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">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?</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> -- Justin</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On 10/13/2016 7:17 PM, George Fletcher wrote:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">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.</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">In general, this ambiguous behavior does make it difficult to write well behaved clients, and seems like something that should be addressed going forward.</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Thanks,</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">George</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On 10/13/16 5:00 PM, Phil Hunt (IDM) via Openid-specs-ab wrote:</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">The registration response is simply undefined. The client cannot infer any meaning by an absence. </span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I would expect the client to retry during the authz step. It can always be refused again. </span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Phil</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On Oct 13, 2016, at 4:54 PM, Justin Richer <<a href="mailto:jricher@mit.edu" class="">jricher@mit.edu</a>> wrote:</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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? </span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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?</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> — Justin</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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:</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">The server is certainly right to ignore a scope request that it doesn’t understand, per this language at <a href="https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse:" class="">https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse:</a></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">From an RFC 7591, the server’s behavior seems fine to me too. <a href="https://tools.ietf.org/html/rfc7591#section-2" class="">https://tools.ietf.org/html/rfc7591#section-2</a> says:</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> The implementation and use of all client metadata fields is OPTIONAL, unless stated otherwise.</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Likewise, it also adds:</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> The</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> authorization server MUST ignore any client metadata sent by the</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> client that it does not understand (for instance, by silently</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> removing unknown metadata from the client's registration record</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> during processing). The authorization server MAY reject any</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> requested client metadata values by replacing requested values with</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> suitable defaults as described in Section 3.2.1 or by returning an</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> error response as described in Section 3.2.2.</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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.</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> -- Mike</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">From: Openid-specs-ab [<a href="mailto:openid-specs-ab-bounces@lists.openid.net" class="">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Justin Richer via Openid-specs-ab</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Sent: Thursday, October 13, 2016 1:28 PM</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">To: Phil Hunt <<a href="mailto:phil.hunt@oracle.com" class="">phil.hunt@oracle.com</a>></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Cc: <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>></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Subject: Re: [Openid-specs-ab] Interaction between OIDC Registration and RFC7591</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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. </span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> — Justin</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On Oct 13, 2016, at 10:49 AM, Phil Hunt <<a href="mailto:phil.hunt@oracle.com" class="">phil.hunt@oracle.com</a>> wrote:</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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.</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">If scope was not accepted, it simply means defaulting not supported and the client should authorize as normal. </span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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.</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Phil</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">@independentid</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="http://www.independentid.com/" class="">www.independentid.com</a></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="mailto:phil.hunt@oracle.com" class="">phil.hunt@oracle.com</a></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On Oct 13, 2016, at 7:51 AM, Justin Richer via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">We've come across an interesting interaction between related specs.</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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.</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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.</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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.</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span 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.</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">-- Justin</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Openid-specs-ab mailing list</span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Openid-specs-ab mailing list</span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br class=""></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Openid-specs-ab mailing list</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br class=""></blockquote><span class=""></span><br class=""><span class="">-- Roland</span><br class=""><span class="">"Education is the path from cocky ignorance to miserable uncertainty.” - Mark Twain</span><br class=""><span class=""></span><br class=""><span class=""></span><br class=""><span class=""></span><br class=""><span class="">_______________________________________________</span><br class=""><span class="">Openid-specs-ab mailing list</span><br class=""><span class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a></span><br class=""><span class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br class=""></div></blockquote></div></div>_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></div></blockquote></body></html>