[Openid-specs-ab] Spec call notes 13-Feb-12
jricher at mitre.org
Wed Feb 15 14:18:20 UTC 2012
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
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.
On 02/14/2012 07:31 PM, John Bradley wrote:
> On 2012-02-14, at 11:14 AM, Justin Richer wrote:
>>> #510 and #536 - Messages, Basic - Proposal for adding hash to
>>> 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
>>> 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
>>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab