<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
The code is already audience restricted at the AS, as long as the AS
is doing its job. Consider:<br>
<br>
1) User shows up at AS authz endpoint for OIC login, carries
client_id with them<br>
2) AS generates a code, internally ties it to that client_id<br>
3) AS generates an id_token, ties it to that client_id (and does a
strong binding by signing it with an audience field, so a good
client can validate it)<br>
4) Client shows up at the AS's token endpoint with a code, carries
client_id/client_secret with it<br>
5) AS looks up what client_id that code was tied to, verifies it
against the one coming in on the request<br>
6) If they match, AS issues a token, id_token, etc.<br>
<br>
If someone else gets the code in transit, they also need to have the
client credentials in order to use it. Stuffing it into the id_token
doesn't actually help, unless I'm missing why.<br>
<br>
-- Justin<br>
<br>
On 02/14/2012 07:31 PM, John Bradley wrote:
<blockquote
cite="mid:7CF17070-B01B-4862-8418-196A833A85AF@ve7jtb.com"
type="cite"><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 moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<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><br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>