<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">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.<br>
<br>
In general, this ambiguous behavior does make it difficult to
write well behaved clients, and seems like something that should
be addressed going forward.<br>
<br>
Thanks,<br>
George<br>
</font><br>
<div class="moz-cite-prefix">On 10/13/16 5:00 PM, Phil Hunt (IDM)
via Openid-specs-ab wrote:<br>
</div>
<blockquote
cite="mid:67FCFB0D-9675-4367-B397-B8C7158C9171@oracle.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>The registration response is simply undefined. The client
cannot infer any meaning by an absence. </div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">I would expect the client to retry
during the authz step. It can always be refused again. <br>
<br>
Phil</div>
<div><br>
On Oct 13, 2016, at 4:54 PM, Justin Richer <<a
moz-do-not-send="true" href="mailto:jricher@mit.edu">jricher@mit.edu</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 style="font-family:
Verdana, sans-serif;" class="" lang="EN">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
moz-do-not-send="true"
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
style="font-family: 'Courier New';" class=""
lang="EN"> 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 class="" lang="EN"> 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 class="" lang="EN"> 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 class="" lang="EN"> 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 class="" lang="EN"> 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 class="" lang="EN"> 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 class="" lang="EN"> 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 class="" lang="EN"> suitable defaults as described in <a moz-do-not-send="true" 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 class="" lang="EN"> error response as described in <a moz-do-not-send="true" 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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
class="">openid-specs-ab@lists.openid.net</a>
Ab <<a moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>