[Openid-specs-ab] access tokens and delegation

Breno de Medeiros breno at google.com
Fri Feb 18 22:53:08 UTC 2011


On Fri, Feb 18, 2011 at 14:52, Breno de Medeiros <breno at google.com> wrote:

>
>
> On Fri, Feb 18, 2011 at 08:24, Nat Sakimura <sakimura at gmail.com> wrote:
>
>> To everybody who was in the f2f this week, thanks very much. It was a very
>> productive session.
>>
>> Couple of questions to the decisions reached in the meeting:
>>
>> *1. UserInfo Endpoint as the access_token exchange. *
>>
>> If unlike the current draft the UserInfo Endpoint was to return the
>> access_tokens for each endpoints instead of the AuthZ Server, i.e., the
>> AuthZ Server just returns the access_token for the UserInfo Endpoint, then
>> this access_token for the UserInfo Endpoint MUST contain all the attribute
>> requests either explicitly or by reference. Is that correct?
>
>
> No. I think the plan is to have a single access_token or code that codifies
> access to everything.
>
>
>>
>> *2. Migration / Delegation*
>>
>> We did not quite get to talk about delegation explicitly but talked it in
>> terms of the identifier migration. Well, identifier migration is a kind of
>> Delegation really. When I thought a little about various use cases, I came
>> to the conclusion that we probably want delegation, perhaps though in a
>> limited manner.
>>
>> In the Migration / Delegation scenario, there are three actors:
>>
>> (a) The identifier issuer (iss)
>> (b) The user (user) that this identifier (id) points to
>> (c) The delegated server (ds)
>>
>>
>> To make it work, the following has to happen.
>>
>> (1) The identifier cannot be any random string, but be a pair of the iss
>> and the id string. It could be formed into a URI or can be a JSON structure.
>> Per the previous discussion in November, we are probably taking the later
>> approach. So, it will look like:
>>
>> {"iss":"issuer_domain",
>>  "id":"user_id""}
>>
>>
>>
> Well, yes, but the JWT token already has a place for the issuer so there's
> no need to specify this beyond saying that this is a JWT token encoding the
> 'id'
>
>
>> (2) The "iss" MUST authoritatively indicate that it wants to delegate to
>> "as". This has to be indicated by another parameter, e.g., "ds". So, the
>> structure will look like:
>>
>> {"iss":"issuer_domain",
>>  "id":"user_id",
>>  "ds":"delegated_server_id"}
>>
>>
>>
> I don't understand how the above follows. Let's re-structure the current
> core draft to capture the framework we discussed, then we can go into
> details such as this.
>
>
>> (3) The structure MUST be signed by the iss using its private key to show
>> that "iss" is authoritatively delegating authorization to "ds": using
>> symmetric key here will complicate things greatly, so asymmetric key crypto
>> is the only viable way. In our current way of thinking, it will be a JWT,
>> and the "iss" in the header MUST be the same as the "iss" in the full
>> identifier.
>>
>> So, the JWT claim (payload) segment now will look like:
>>
>> {"iss":"issuer_domain",
>>  "id":"user_id",
>>  "ds":"delegated_server_id",
>>  "alg":"RS256",
>>  "exp":"1300752001"}
>>
>> And the JWT header segment will look like:
>>
>> {"alg":"RS256",
>>  "x5u":"http://example.com/certs.pem"}
>>
>>
>> The resulting JWT is as usually a three segment string with
>> header.payload.signature.
>>
>> The resulting JWT string is the delegation token. By sending this in the
>> UserInfo Endpoint response, the receiver can verify that this delegation /
>> migration is authoritative by first checking the validity of the delegation
>> token, then comparing that "ds" is the server that it is talking to.
>>
>> Right?
>>
>> =nat
>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>> http://twitter.com/_nat_en
>>
>
>
>
> --
> --Breno
>



-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110218/7d136dbd/attachment.html>


More information about the Openid-specs-ab mailing list