To everybody who was in the OpenID ABC 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?