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

Justin Richer jricher at mitre.org
Fri Dec 14 21:10:19 UTC 2012

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 <mailto: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
>     <http://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

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

More information about the Openid-specs-ab mailing list