[Openid-specs-ab] Spec call notes 13-Feb-12

John Bradley ve7jtb at ve7jtb.com
Wed Feb 15 15:27:29 UTC 2012

Yes code is effectively audience restricted to the client  by the client secret or some equivalent authentication mechanism.

I originally argued that we should only worry about the access_token and not code.

However Google thinks there is still a vulnerability caused by swapping code between users destined for the same client. State is not signed so it is easy to do.

It is a much smaller attack than swapping out the access token, but at least theoretically possible.

I am mostly the messenger on this one.  The requirement is coming from Google.

One option is for the WG to decide swapping code between id_tokens is not a three that warrants mandatory protection and increasing the size of the id_token.

I think adding the hash of the access token is less controversial.

John B.
On 2012-02-15, at 11:18 AM, Justin Richer wrote:

> The code is already audience restricted at the AS, as long as the AS is doing its job. Consider:
> 1) User shows up at AS authz endpoint for OIC login, carries client_id with them
> 2) AS generates a code, internally ties it to that client_id
> 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)
> 4) Client shows up at the AS's token endpoint with a code, carries client_id/client_secret with it
> 5) AS looks up what client_id that code was tied to, verifies it against the one coming in on the request
> 6) If they match, AS issues a token, id_token, etc.
> 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.
>  -- Justin
> On 02/14/2012 07:31 PM, John Bradley wrote:
>> On 2012-02-14, at 11:14 AM, Justin Richer wrote:
>>> Issues
>>>>     #510 and #536 - Messages, Basic - Proposal for adding hash to id_token
>>>>         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.
>>>>         Issue 536 is the actual proposal from John. His proposal is to modify the 'code id_token' and 'code token id_token' response_types 
>>>>         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. 
>>>>         It is also more in line with Facebook's signed request method. The ID Token is also modified to include an optional access 
>>>>         token fingerprint.  For full proposal, please see http://hg.openid.net/connect/issue/536/messages-multi-token-response-add-hash-of .
>>>>         John will send proposal to the mailing list for feedback.
>>> 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 
>> This is about the response from the Authorization server and the ability for users to swap tokens.
>> So signed response.
>> Given that the signed part of the response is the id_token there are essentially two choices:
>> 1 include the value in the id_token as a claim
>> 2 include a hash of the value in the id_token as a claim.
>> 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.
>> 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.
>> 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.
>> John
>>>>     #513 Basic 1.2, Messages 8.14, Discovery 3.1, 3.2 - Issuer Identifier can not contain a path component
>>>>         John made proposal to add a path component to the issuer returned from Simple Web Discovery and append ".well-known/openid-configuration"
>>>>         to the returned issuer string to retrieve the specific configuration information.
>>>>         John has sent this proposal to the list but has not received much feedback.
>>>>         This issue will be discussed at a face to face meeting in the upcoming RSA conference.
>>> 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.
>>>  -- Justin
>>> _______________________________________________
>>> 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/20120215/6b2677f4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120215/6b2677f4/attachment-0001.p7s>

More information about the Openid-specs-ab mailing list