<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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>
</body>
</html>