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

John Bradley ve7jtb at ve7jtb.com
Wed Feb 15 00:31:28 UTC 2012

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.


>>     #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/20120214/4a2d3316/attachment.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/20120214/4a2d3316/attachment.p7s>

More information about the Openid-specs-ab mailing list