[Openid-specs-ab] access tokens and delegation

Nat Sakimura sakimura at gmail.com
Fri Feb 18 16:24:51 UTC 2011


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?

*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""}


(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"}


(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110219/0f11a0bd/attachment.html>


More information about the Openid-specs-ab mailing list