[Openid-specs-ab] [openid/connect] Messages - Add 'prn' claim to id_token to support JWT Assertion (issue #687)

Wed Dec 19 19:36:59 UTC 2012

The idea here was to treat the id_token as if it were an access token, 
but what it's accessing is a set of APIs for managing the session. These 
APIs include closing the session (via the revocation endpoint), querying 
the session status (via the introspection endpoint), and refreshing the 
session (via the token endpoint). It's this last operation that I was 
looking at using the JWT Assertion spec for. You would effectively push 
your existing id_token into the token endpoint along with your client 
credentials and get back out a new id_token. This new id_token would 
have all the same claims as the first one, except that its expiration 
would now be later in the future. Note that this would probably 
invalidate the existing one (it does in our implementation, but that's 
because we're calling out id_tokens specifically).

In any case, you don't pass any scopes with this call, because the 
id_token is essentially scopeless from an OAuth perspective. In our 
implementation, it happens to get a special "id-token" scope that 
clients aren't allowed to ask for explicitly, but that's a service 
detail and I wouldn't consider the id_token itself to have any *real* 
scope to speak of.

I've always seen the id_token as a session-bound access token, and 
ultimately the handle that the client can use for session management and 
information. Google's current session management javascript cookie hack 
gets away from this and introduces another value for this purpose. Nat's 
(and others') use cases for a "fat" id_token also get away from this 
somewhat, but in a little less onerous manner. (In that, it makes it a 
little more cumbersome because the token is large, but the process is 
identical).

 From a functional perspective, I would be nearly as happy with a 
different grant that lets me explicitly hand back an id_token and get a 
new id_token with these properties. I was hoping to use as much existing 
capability as I could, which led me down the JWT Assertion path and 
opened up this whole can of worms.

  -- Justin

On 12/18/2012 07:01 PM, Brian Campbell wrote:
> BTW Justin, I got focused on other aspect of all this and forgot that
> I wanted to ask you what (assuming aud and prn/sub/who/etc work out)
> this exchange actually looked like? The JWT Assertion is designed for
> the case of trading a JWT for an access token but it sounds like you
> are using it to get an id token? Is that in place of the access token
> or does it supplement it?  Do you send an openid scope in the request?
> Just curious really...
>
> On Fri, Dec 14, 2012 at 3:40 PM, Justin Richer <jricher at mitre.org> wrote:
>> You are correct. I hadn't caught that, but it does state in JWT Assertions:
>>
>> The JWT MUST contain an aud (audience) claim containing a URI reference that
>> identifies the authorization server, or the service provider principal
>> entity of its controlling domain, as an intended audience. The token
>> endpoint URL of the authorization server MAY be used as an acceptable value
>> for an aud element. The authorization server MUST verify that it is an
>> intended audience for the JWT.
>>
>>
>> Which doesn't leave much wiggle room for the OIDC interpretation. Between
>> this an 'prn', maybe this is a different kind of assertion claim, then? An
>> id-token assertion grant type?
>>
>>   -- Justin
>>
>>
>> On 12/14/2012 04:51 PM, Brian Campbell wrote:
>>
>> I believe the current wording of the specs would prohibit that.
>>
>>
>>
>>
>> On Fri, Dec 14, 2012 at 2:10 PM, Justin Richer <jricher at mitre.org> wrote:
>>> My original idea is for the Client to use the JWT Assertion flow with a
>>> current id_token to refresh it and get a new id_token. This goes back to the
>>> session management proposal linked to within the issue. In this case, the
>>> audience for the token really *is* the client, and an AS will need to look
>>> for that.
>>>
>>>   -- Justin
>>>
>>>
>>> On 12/14/2012 04:04 PM, Brian Campbell wrote:
>>>
>>> I had a comment/question related to the below comment on issue 687 but not
>>> really related to the issue itself. So figured the list would be the best
>>> forum.
>>>
>>> Regarding the potential use of an ID Token as an assertion in the OAuth
>>> JWT Assertion Profile - aren't the requirements around the "aud" claim also
>>> potentially a problem?
>>>
>>> Connect says the aud of an ID Token "MUST be the OAuth 2.0 client_id of
>>> the Client." While the OAuth JWT Assertion Profile is a little more flexible
>>> but basically says the aud must identify the AS or its controlling entity.
>>> Doesn't this imply that an ID Token could only really be used to get an
>>> access token within the scope of the client to whom it was sent in the first
>>> place? Which doesn't seem very useful. Or is it?
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Dec 13, 2012 at 5:23 PM, Michael Jones
>>> <issues-reply at bitbucket.org> wrote:
>>>> --- you can reply above this line ---
>>>>
>>>> Issue 687: Messages - Add 'prn' claim to id_token to support JWT
>>>> Assertion
>>>>
>>>> https://bitbucket.org/openid/connect/issue/687/messages-add-prn-claim-to-id_token-to
>>>>
>>>> Michael Jones:
>>>>
>>>>
>>>> I agree that it would be a shame, architecturally, if we can't use an ID
>>>> Token as a assertion in a way that complies with the OAuth JWT Assertion
>>>> Profile.  I believe we need to address this.
>>>>
>>>> There are few ways to do this, as I see it:
>>>>
>>>> 1.  Add "prn" to the ID Token.  Upside:  Simple.  Downsides:  Wastes
>>>> space through duplication of data; potential interop problem where not
>>>> everyone duplicates or uses the information in the same way.
>>>>
>>>> 2.  Replace "user_id" with "prn" in the ID Token.  Downside:  Less
>>>> mnemonic than user_id.  Upside:  simple.
>>>>
>>>> 3.  Modify the OAuth JWT Assertion Profile to allow the subject to be
>>>> identified by a claim other than "prn" - possibly explicitly calling out
>>>> "user_id".  Upside:  would work.  Downside:  Codifies inconsistency.
>>>>
>>>> 4.  Replace both "user_id" and "prn" with a different claim in both
>>>> specs.  Candidates include "id" and "sub".
>>>>
>>>> Let's make this a topic for Monday's call.
>>>>
>>>>
>>>> --
>>>>
>>>> This is an issue notification from bitbucket.org. You are receiving
>>>> this either because you are the owner of the issue, or you are
>>>> following the issue.
>>>
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>