<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 2012-02-14, at 11:14 AM, Justin Richer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
Issues<br>
<blockquote cite="mid:1329180989.78323.YahooMailRC@web181310.mail.ne1.yahoo.com" type="cite">
<div style="font-family: tahoma,new york,times,serif; font-size:
10pt; color: rgb(0, 0, 0);">
<div> #510 and #536 - Messages, Basic - Proposal for adding
hash to id_token<br>
Issue 510 is the issue asking for a proposal for
adding a hash of the code and/or access token along with the
ID Token.<br>
Issue 536 is the actual proposal from John. His
proposal is to modify the 'code id_token' and 'code token
id_token' response_types <br>
to include the code as a claim inside the id_token.
Since id_token is signed, the code is automatically checked by
the id_token signature. <br>
It is also more in line with Facebook's signed request
method. The ID Token is also modified to include an optional
access <br>
<span> token fingerprint. For full proposal, please
see <a moz-do-not-send="true" target="_blank" href="http://hg.openid.net/connect/issue/536/messages-multi-token-response-add-hash-of">http://hg.openid.net/connect/issue/536/messages-multi-token-response-add-hash-of</a></span>
.<br>
John will send proposal to the mailing list for
feedback.<br>
<br>
</div>
</div>
</blockquote>
<br>
I'm not a fan of mixing the two tokens, or making the ID token
bigger than it needs to be. Also, it's a redundancy of information
between what's in the token and what's in the real parameters.
Again, I think this is just asking for a signed HTTP request (with
all parameters signed) more than anything. That would protect the
parameters from modification in transit <br>
<br></div></blockquote><div>This is about the response from the Authorization server and the ability for users to swap tokens.</div><div><br></div><div>So signed response.</div><div><br></div><div>Given that the signed part of the response is the id_token there are essentially two choices:</div><div>1 include the value in the id_token as a claim</div><div>2 include a hash of the value in the id_token as a claim.</div><div><br></div><div>Given that the hash of the code and code are going to be about the same size likely the id_token size itself is a wash and the overall response size is smaller because you are not sending the hash.</div><div><br></div><div>With access_token, we can only include the hash as we don't want the value to leak from setting the id-token as a cookie.</div><div><br></div><div>If someone has another way of tying the code and access token to the id_token or otherwise audience restricting them to the client, speak up now.</div><div><br></div><div>John</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<blockquote cite="mid:1329180989.78323.YahooMailRC@web181310.mail.ne1.yahoo.com" type="cite">
<div style="font-family:tahoma,new
york,times,serif;font-size:10pt;color:#000000;">
<div><br>
#513 Basic 1.2, Messages 8.14, Discovery 3.1, 3.2 - Issuer
Identifier can not contain a path component<br>
John made proposal to add a path component to the
issuer returned from Simple Web Discovery and append
".well-known/openid-configuration"<br>
to the returned issuer string to retrieve the specific
configuration information.<br>
John has sent this proposal to the list but has not
received much feedback.<br>
This issue will be discussed at a face to face meeting
in the upcoming RSA conference.<br>
</div>
</div>
</blockquote>
<br>
I agree with this proposal, as it is problematic to require
site-root-level access beyond the first static discovery step. This
would partially address another issues that I'd reported, about the
openid-configuration being redirectable using SWD semantics, since
the SWD service wouldn't have to point at the root of a server
anymore.<br>
<br>
-- Justin<br>
</div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></body></html>