<html><head><meta http-equiv="Content-Type" content="text/html; charset=windows-1256" /></head><body bgcolor="#FFFFFF">at_hash is intended to protect the access token conveyed via the front channel from substitution. It should therefore be validated against this access token only. Why not just stating this?<br><br><div class="gmail_quote"><br>
<br>
Mike Jones <Michael.Jones@microsoft.com> schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">





<div>
<div style="font-size:11pt; font-family:Calibri,sans-serif">Yes, because of at_hash, we need normative text so clients don't break when they assume the values will be the same.<br />
</div>
</div>
<div dir="ltr">
<hr />
<span style="font-size:11pt; font-family:Calibri,sans-serif; font-weight:bold">From:
</span><span style="font-size:11pt; font-family:Calibri,sans-serif"><a href="mailto:gffletch@aol.com">George Fletcher</a></span><br />
<span style="font-size:11pt; font-family:Calibri,sans-serif; font-weight:bold">Sent:
</span><span style="font-size:11pt; font-family:Calibri,sans-serif">‎12/‎2/‎2013 12:55 PM</span><br />
<span style="font-size:11pt; font-family:Calibri,sans-serif; font-weight:bold">To:
</span><span style="font-size:11pt; font-family:Calibri,sans-serif"><a href="mailto:Michael.Jones@microsoft.com">Mike Jones</a>;
<a href="mailto:issues-reply@bitbucket.org">Nat Sakimura</a>; <a href="mailto:openid-specs-ab@lists.openid.net">
openid-specs-ab@lists.openid.net</a></span><br />
<span style="font-size:11pt; font-family:Calibri,sans-serif; font-weight:bold">Subject:
</span><span style="font-size:11pt; font-family:Calibri,sans-serif">Re: [Openid-specs-ab] Issue #907: Core - 2.3.3.8. Access Token - ATs should be different. (openid/connect)</span><br />
<br />
</div>
<div><font face="Helvetica, Arial, sans-serif">Do we need to have any normative text about whether the tokens are different or the same? I like the idea of adding text to the security considerations to address the issue of trust/scopes/etc. However, from a
 normative perspective the phrase "their values MAY be the same or in some cases, they might be different" is very weak and doesn't really help at all. To me it reads, don't expect/assume the access tokens to be the same. If we need normative text, what about
 something like...<br />
<br />
If an Access Token is returned from both the Authorization Endpoint and from the Token Endpoint, which is the case with the response_type values 'code token' and 'code id_token token', there is no expectation that the values will be the same.<br />
<br />
Thanks,<br />
George</font><br />
<br />
<div class="moz-cite-prefix">On 12/2/13 2:17 PM, Mike Jones wrote:<br />
</div>
<blockquote type="cite">
<pre>I have two problems with the proposed text.  First, and foremost, if we recommend that the two access tokens be different, we're making simple things complicated, which is the opposite of our design philosophy.  I would expect that a normal implementation would return an access token that's appropriate for the front channel on the front channel and then return the same access token on the back channel.  If it's safe enough for the front channel, it's also safe on the back channel.  That's keeping simple things simple.

Returning different access tokens is an advanced case, which I'll note that we have no syntax for governing.  The scopes and "claims" logic just talk about *the* access token, not multiple access tokens, nor do we want to introduce new syntax to differentiate between them now.  We shouldn't be recommending advanced behavior that is incompletely specified.

Secondly, the second sentence should actually be part of the security considerations - not the normative text about this case.  It would be fine to include this as part of a general treatment about the security differences between tokens returned on the front channel and on the back channel.  If you want to propose specific security considerations text along those lines, I'd welcome that.  But this doesn't belong here.

Therefore, I believe that this proposal should be rejected, and possibly replaced by a new proposal for additional security considerations text.

    -- Mike

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Nat Sakimura
Sent: Monday, December 02, 2013 9:00 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>
Subject: [Openid-specs-ab] Issue #907: Core - 2.3.3.8. Access Token - ATs should be different. (openid/connect)

New issue 907: Core - 2.3.3.8. Access Token - ATs should be different.
<a class="moz-txt-link-freetext" href="https://bitbucket.org/openid/connect/issue/907/core-2338-access-token-ats-should-be">https://bitbucket.org/openid/connect/issue/907/core-2338-access-token-ats-should-be</a>

Nat Sakimura:

Current text states: 

If an Access Token is returned from both the Authorization Endpoint and from the Token Endpoint, which is the case with the response_type values code token and code id_token token, their values MAY be the same or in some cases, they might be different.

In my comments back in October 22, I have pointed out that they should be different and provided the following text. The WG also have agreed that they should be different as the security property is different. Therefore, I propose to adopt the text provided on Oct. 22, which is: 

If an Access Token is returned from both the Authorization Endpoint and from the Token Endpoint, which is the case with the response_type values code token and code id_token token, it is RECOMMENDED that their values be different. The access token returned from Authorization Endpoint is more vulnerable to various attacks so that it has less trust than that returned from the Token Endpoint. Thus, the Server MAY give lesser scope and/or shorter lifetime for the Access Token that is returned from the Authorization Endpoint. 


_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<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>
_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<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>


</pre>
</blockquote>
<br />
<div class="moz-signature">-- <br />
<a href="http://connect.me/gffletch" title="View full card on
        Connect.Me"><img src="cid:part1.06050206.00010402@aol.com" alt="George Fletcher" height="113" width="359" /></a></div>
</div>


<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />Openid-specs-ab mailing list<br />Openid-specs-ab@lists.openid.net<br /><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br /></pre></blockquote></div></body></html>