[Openid-specs-ab] access tokens and delegation

Breno de Medeiros breno at google.com
Fri Feb 18 22:52:14 UTC 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110218/73c6ae38/attachment-0001.html>


More information about the Openid-specs-ab mailing list