<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">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. <br>
<br>
In general, for clients, I prefer to always be explicit with
requested scopes rather than relying on a pre-registered default
scope set.<br>
<br>
Thanks,<br>
George<br>
</font><br>
<div class="moz-cite-prefix">On 10/14/16 10:13 PM, Justin Richer
wrote:<br>
</div>
<blockquote cite="mid:bf035fa0-a1d9-7228-6e97-61ed737c8782@mit.edu"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<p>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?</p>
<p> -- Justin<br>
</p>
<br>
<div class="moz-cite-prefix">On 10/13/2016 7:17 PM, George
Fletcher wrote:<br>
</div>
<blockquote
cite="mid:371b6a9d-6c8a-459d-1da8-9a7e63141e90@aol.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<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">
<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> 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" 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>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>