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

Brian Campbell bcampbell at pingidentity.com
Fri Dec 14 21:51:03 UTC 2012


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 listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121214/915c0f3c/attachment-0001.html>


More information about the Openid-specs-ab mailing list