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

[Justin Richer]

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 
>> <mailto: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/541522fc/attachment.html>