OK. You are right. <div><br></div><div>That's slightly better, but still dealing with the permutation is not fun. </div><div><br></div><div>I should probably take some sleep before further ranting :-)</div><div><br></div>
<div>=nat<br><div><br><div class="gmail_quote">On Wed, Feb 15, 2012 at 12:51 AM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Not necessarily -- you're not required to support all registered
types, so you only need to parse the registry when you're changing
which request types you support. You should still be allowed to
reject something that you don't recognize or support as "invalid"
even if it's been registered, as far as I can tell. The registry is
just meant to prevent namespace collisions, not to give a checklist
for implementors to deal with.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- Justin</font></span><div><div class="h5"><br>
<br>
On 02/14/2012 10:49 AM, Nat Sakimura wrote:
<blockquote type="cite">
That's exactly the point.
<div><br>
</div>
<div>If someone did not register "code token id_token
signed_request", </div>
<div>even if individual elements are registered, it MUST be
treated as invalid. </div>
<div>
But at the same time, if someone registered it, it has to be
enabled. </div>
<div>That means, the implementations MUST keep parsing the IANA
registry, </div>
<div>which is not particularly well structured nor guaranteed to
be very scalable. </div>
<div><br>
</div>
<div>=nat</div>
<div><br>
<div class="gmail_quote">On Wed, Feb 15, 2012 at 12:46 AM, John
Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">"id_token signed_request"
would be valid if someone registered it. You could have
it return code and no id_token or something else
unexpected.
<div><br>
</div>
<div>I am OK with having id_token_code for the response
with code in id_token.</div>
<span><font color="#888888">
<div><br>
</div>
</font></span>
<div><span><font color="#888888">John</font></span>
<div>
<div><br>
<div>
<div>On 2012-02-14, at 12:24 PM, Nat Sakimura
wrote:</div>
<br>
<blockquote type="cite">Indeed. Treating any
permutation of "code token id_token" the same
and treating "code token id_token
signed_request" undefined is way too much work
for both parties.
<div><br>
</div>
<div>One of our lead developer was so cynical to
say that "OK. Let us define 100 response types
tokens and register permutation of them and
see if it does not blow up the registry." </div>
<div><br>
</div>
<div>=nat<br>
<br>
<div class="gmail_quote">On Wed, Feb 15, 2012
at 12:17 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">In the
OAuth WG there was a proposal for making
return_type multi valued. That was
killed by people who din't want a
breaking change.
<div>So the compromise was to keep it as
a single value but allow spaces so
people could pretend it is multi
valued.</div>
<div><br>
</div>
<div>The advantage is the client can say
"code token" or "token code" and the
authorization server MUST treat them
as equivalent.</div>
<div><br>
</div>
<div>This is more work for the
Authorization server and probably just
confuses the client developer about
what is happening. </div>
<div><br>
</div>
<div>Why when I ask for code is it
returned as a query parameter, but
returned fragment encoded when I ask
for "code token". Pretending the
individual elements have independent
meaning leads people to wrong
conclusions.</div>
<div><br>
</div>
<div>I don't want to try and change
OAuth itself now. </div>
<div><br>
</div>
<div>However we could decide to use an
underscore rather than space to make
it clearer to developers that it is a
single value.</div>
<div><br>
</div>
<div>John B.
<div>
<div><br>
<div>
<div>On 2012-02-14, at 11:41 AM,
Nat Sakimura wrote:</div>
<br>
<blockquote type="cite">Coping
with all the permutations but
not the combinations seems to
be a fairly bad task.
<div>
getting rid of spaces and
connecting with an
underscore seems to simplify
the code. </div>
<div>If it were array, it were
ok, but it is not. </div>
<div><br>
</div>
<div>=nat</div>
<div><br>
<div class="gmail_quote">On
Tue, Feb 14, 2012 at 11:27
PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">It's
all in the response
type registration.
<div><br>
</div>
<div>Remember response
type is a <b>Single
Value</b> that may
contain spaces.
This is perhaps
proving to be the
most confusing thing
about the OAuth 2
spec.</div>
<div><br>
</div>
<div>There is no real
difference between
id_token_code and
"id_token code"
other than the fact
that when you
register "id_token
code" you are also
registering "code
id_token" as an
alias.</div>
<div><br>
</div>
<div>There is <b>NO </b>relationship
between the string
code on it's own and
the string code
occurring in
combination with any
other string in the
return type.</div>
<div><br>
</div>
<div>That said it is
probably best to
reduce the confusion
that developers will
inevitably have not
understanding that.</div>
<div><br>
</div>
<div>We can change the
registration for the
string "id_token
code" to say that
you get back a
single fragment
encoded parameter
"id_token"
containing code as a
claim value.</div>
<div>We can change the
registration for the
string "id_token
code token" to say
that you get back
two fragment encoded
parameters
"id_token"
containing code as a
claim value and
access_token
containing a access
token.</div>
<div><br>
</div>
<div>I should point
out the
response_type token
returns several
parameters none of
which are called
token i.e.
access_token,
token_type,
expires_in, and
scope. The symmetry
is imaginary.</div>
<div><br>
</div>
<div>To Rolland's
point about needing
to unpack the
id_token, the
current logic is
that you MUST unpack
and verify the
id_token directly or
by using the
check_id endpoint.</div>
<div>In my proposal
you take the element
code from the
id_token and you are
done.</div>
<div>In the alternate
proposal, you MUST
do all that then
take the
token_thumbprint
parameter and
compare it to a
truncated hash of
code. adding
several steps that
cause this to be
less secure and more
complicated.</div>
<div><br>
</div>
<div>One alternative
might be to get rid
of the confusing
space separated
multi token return
types.</div>
<div><br>
</div>
<div>Register
id_token_code and
id_token_code_token
to make it clear
that we are not
implying a
connection to the
reregistered code
response type. </div>
<div>We could leave
id_token code as is
for those that don't
care about
validating code, or
deprecate it.</div>
<div><br>
</div>
<div>My concern is
that 90% of
developers will
never check the hash
if we include the
hash of code in
id_token. If we
include code in the
id_token
verification happens
automatically.</div>
<div><br>
</div>
<div>The other issue
is that Google is
already putting the
hash of code in
id_token so they
would need to agree
to the change. </div>
<div><br>
</div>
<div>If there is more
support for
including the hash
of code in the
id_token, so that
the response is
larger and more work
to process, and most
developers will
ignore it anyway, I
am OK with that.</div>
<div><br>
</div>
<div>I just want
people to understand
the options, so that
when everyone sea
why didn't you
include code in
id_token like
Facebook is doing
with signed_request,
how come I can't
reuse the code I
have for Facebook,
I can say we
discussed it and
decided it was not
the correct option.</div>
<div><br>
</div>
<div>John B.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div>
<div>
<div>
<div>On
2012-02-14, at
6:23 AM,
Roland Hedberg
wrote:</div>
<br>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div><br>
14 feb 2012
kl. 09:33
skrev Nat
Sakimura:<br>
<br>
<blockquote type="cite">So,
in today's WG
Call, John
explained that
it was what FB
was doing, and
would probably
be simpler for
developers.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">(It
is tracked as
<a href="https://bitbucket.org/openid/connect/issue/536/" target="_blank">https://bitbucket.org/openid/connect/issue/536/</a>
)<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">I
checked with
Tatsuya, who
is building
solutions for
our customer
and he said it
indeed would
be simpler, so
that is a good
news.<br>
</blockquote>
<br>
I'm not sure
it will be
simpler, it
will add
another
packing/unpacking
layer.<br>
<br>
<blockquote type="cite">My
concern is
semantics.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">As
I understand,
scope is
something that
request what
is to be
returned
overall, and
response_type
is a parameter
that request
what is to be
returned from
the
Authorization
endpoint
response
parameters.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">So,
if
response_type=code,
code is
returned from
the Authz EP,
and if
response_type=token,
token is
retunred from
the Authz EP.
Expanding on
this
semantics,
response_type=code
id_token would
mean that code
and id_token
has to be
returned from
Authz EP as
independent
parameters. If
code is to be
returned as
part of the
id_token, I
feel that it
should be just
id_token, or a
new response
type such
ascode_in_id_token.<br>
</blockquote>
<br>
Agree!<br>
So basically
we have a set
of components
some of which
could become
part of
another
component.<br>
Either it's
done implicit,
that is the
smallest
number of
components are
supposed to be
send.<br>
So, if "code
id_token" is
requested and
code can be
included in
the id_token
then an
id_token would
be transmitted
with code
inside.<br>
On the other
hand would to
do when "code
token" is
requested ? <br>
Neither of
them could
contain the
other. <br>
Would an
id_token be
used then as a
wrapper
containing
only the code
and the token.<br>
<br>
To me it
sounds like we
want a new
type of
wrapper object
that could
contain code,
token and
id_token.<br>
Rather than
extend the
existing
id_token
object.<br>
<br>
-- Roland<br>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab
mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Nat Sakimura (=nat)
<div>Chairman, OpenID
Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Nat Sakimura (=nat)
<div>Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Nat Sakimura (=nat)
<div>Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>
</div></div>