[Openid-specs-ab] Issue #907: Core - 2.3.3.8. Access Token - ATs should be different. (openid/connect)

Torsten Lodderstedt torsten at lodderstedt.net
Tue Dec 3 06:11:22 UTC 2013


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?



Mike Jones <Michael.Jones at microsoft.com> schrieb:
>Yes, because of at_hash, we need normative text so clients don't break
>when they assume the values will be the same.
>________________________________
>From: George Fletcher<mailto:gffletch at aol.com>
>Sent: ‎12/‎2/‎2013 12:55 PM
>To: Mike Jones<mailto:Michael.Jones at microsoft.com>; Nat
>Sakimura<mailto:issues-reply at bitbucket.org>;
>openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
>Subject: Re: [Openid-specs-ab] Issue #907: Core - 2.3.3.8. Access Token
>- ATs should be different. (openid/connect)
>
>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...
>
>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.
>
>Thanks,
>George
>
>On 12/2/13 2:17 PM, Mike Jones wrote:
>
>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:
>openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>
>[mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat
>Sakimura
>Sent: Monday, December 02, 2013 9:00 AM
>To:
>openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
>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.
>https://bitbucket.org/openid/connect/issue/907/core-2338-access-token-ats-should-be
>
>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
>Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
>http://lists.openid.net/mailman/listinfo/openid-specs-ab
>_______________________________________________
>Openid-specs-ab mailing list
>Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
>http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>--
>[George Fletcher]<http://connect.me/gffletch>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Openid-specs-ab mailing list
>Openid-specs-ab at lists.openid.net
>http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131203/15e57b89/attachment-0001.html>


More information about the Openid-specs-ab mailing list