[Openid-specs-ab] Obtaining claims without requiring additional round trips

Mike Jones Michael.Jones at microsoft.com
Mon Nov 7 16:11:18 UTC 2011


Your note confuses me.  By saying that the client "may well not understand the claims in the JWT", you could mean two things:
(1) The client may not understand how to retrieve the claims from the JWT.  If true, they could use the UserInfo endpoint to retrieve them (just like they can use the Check ID endpoint to retrieve the ID Token claims).
(2) The client may not understand the meaning of the claims.  If true, they have a problem whether they came directly from the token, or indirectly via the UserInfo endpoint.

Also, your statement about "it gets back code and trades it for two tokens" confuses me too.  It confuses because you're describing a scenario where there's still the additional round trip to obtain the claims.  (It's just a different round trip.)  The request was that the client make the request and be directly returned the claims.  Your description below still requires another round trip.

I also don't see why claims being in the access token precludes people from using the JWT as an access token at a protected resource.  They're not "hijacked" at the client - they're simply directly visible to the client.

You can't be on the call today, right?  When can we have a call that you can be on?

                                                            -- Mike

From: John Bradley [mailto:john.bradley at wingaa.com]
Sent: Monday, November 07, 2011 6:03 AM
To: Nat Sakimura
Cc: Mike Jones; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Obtaining claims without requiring additional round trips

We don't want to preclude people from using JWT as real access tokens intended for the protected resource, because we are hijacking them in the client, who may well not understand the claims in those JWT.

That is why I think it is dangerous to make the default JWT with user-info claims destined for the client.

I could probably be talked into it.

I don't think overloading the id_token with user attribute claims is the right way to go.

At that point we go back to the original AB proposal.

Client requests artifact.

Client trades artifact for signed assertion containing claims.

If servers are not required to have Check ID  or User Info endpoints we need to change Basic to use the code flow.

It gets back code and trades it for two tokens.

It base64decodes the tokens and is good to go, no other endpoints required.

Though that would break everyone who is using a user-info endpoint.

Making JWT with claims the default and making the user-info endpoint optional is a big change, at this point.

John B.



On 2011-11-05, at 7:51 PM, Nat Sakimura wrote:


John,

I am not sure if I understood your point.
So, Mike's requirement is for the user attributes to be returned from Token Endpoint as I understand.
Then why "A viable design some people might want tis to send the claim requests in a signed JWT to the user-info endpoint." would work?

The requirement for id_token to be short is when the client wants to stuff it to the cookie directly.
If the client is sophisticated enough (and we are talking about sophisticated client that can handle crypto itself here), it may as well extract a portion of id_token and put it in the cookie. We have to weight if "short id_token" requirement is more important than "access_token compatibility (i.e., opaque)" requirement.

If we were to use access_token as the carrier for the userinfo, then client should have the way to tell it, and the server should have a way to publish its capability. In fact, the server may publish two endpoints: the legacy token endpoint and JWT token endpoint. The later essentially is a UserInfo endpoint that can interpret the "code".

Mike,

I have a question. Are you talking about the case for the code flow or implicit flow?

=nat


On Sun, Nov 6, 2011 at 4:05 AM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:
Keeping the id_token small is a requirement.  I don't want to start stuffing user attributes in it beyond the user_id.

Another issue is that some IdP may not want to have all of the user attributes available at both the token endpoint and the authorization server.

A viable design some people might want tis to send the claim requests in a signed JWT to the user-info endpoint.

Not all JWT access tokens will contain claim values.

If we make this the default then clients need to check in discovery if they shouldn't sniff the token.
I suppose if the IdP is not publishing a user-info endpoint that could be a hint, but not definitive.

To avoid having the basic client do crypto we would need to use the code flow.  That way the id_token and access token come from a trusted endpoint and can just be base64 decoded.

I think people who are attaching additional scopes to the access token won't use it and will want the opaque token.

One way around that was somehing I had in mind with an earlier draft.
The decoded access token has distributed claims in it.  You could just make the aditional scopes distributed claims, that has the advantage of providing a endpoint URL for the access token, and multiple access tokens.
that was rejected and not being OAuth like at the time.

Unfortunately I won't make the Monday call.

John B.

On 2011-11-05, at 3:30 PM, Nat Sakimura wrote:


So, one possible "another way" would be to have an option to include more user info in the id_token.
That way, we can keep the "opaqueness" requirement for the access_token intact and still accomodate the need for being able to access claims without a second call.

That actually is how it was done in earlier drafts.

=nat
On Sun, Nov 6, 2011 at 1:39 AM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
As discussed during the working group call on Thursday, I received feedback on the current Connect design from a key Microsoft product architect based upon his product's use cases.  The high-order bit in his feedback was that he needs RPs to be able to access claims without making a second call to Check ID or UserInfo endpoints.  Per the discussion on the call, the requirement to be able to access claims without additional round trips seems entirely reasonable and is motivated by real user-interface latency concerns.

To accomplish this, all claims would be carried in JWT tokens, which would then be directly used by the RPs.  This conflicts with the current design decision that the access token is opaque and that UserInfo claims can only be retrieved by making a second call to the UserInfo endpoint.  I propose that we change that decision before declaring implementer's drafts.

Specifically, I would require that, in the normal case, the access token is a JWT containing the UserInfo claims (just like the ID Token is a JWT containing the logged-in session claims).  If we decide that it's important to allow some implementations to use a different token format, that should be the exception, not the default.  In that exceptional case, those IdPs must declare in their discovery information that UserInfo claims must be retrieved from the UserInfo endpoint, and cannot be directly accessed within a JWT access token.

I'd promised on the call to write up this proposed change.  This is that write-up.  We'll discuss this on the Monday call.

                                                            Best wishes,
                                                            -- Mike

P.S.  Coincidentally, I also independently received essentially the same feedback from a different product architect yesterday, based upon his review of the specs.


_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111107/bfdf5890/attachment-0001.html>


More information about the Openid-specs-ab mailing list