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

Mike Jones Michael.Jones at microsoft.com
Sat Dec 15 01:47:00 UTC 2012


I’d added this as a comment on this issue, but I’m also reposting it here so that people just reading the list will see it too.  Let’s make this a topic of Monday’s call.  Justin and Brian, hopefully you can both join that one (even though I know that Monday’s 6pm Eastern Time call time isn’t great for you, Justin).

                                                            -- Mike


1.     I agree that it would be a shame, architecturally, if we can't use an ID Token as an 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", "sub", “sbj”, and “who”.

Let's make this a topic for Monday's call.


From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Friday, December 14, 2012 5:28 PM
To: Brian Campbell
Cc: <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] [openid/connect] Messages - Add 'prn' claim to id_token to support JWT Assertion (issue #687)

Just as a data point, audience (un-restricted | group restricted ) assertion is very useful and common in our daily life. Most of our real life HoK identity documents (drivers license, passport, National I.D.) are in this category, and this property is pretty important when it comes to privacy concerns. In fact, I am working on this issue around OIDC with the Japanese government grant right now.

Nat

Dec 15, 2012 8:12、Brian Campbell <bcampbell at pingidentity.com<mailto:bcampbell at pingidentity.com>> のメッセージ:
That's one way to go.

The assertion drafts are mostly about using the assertion to cross organizational boundaries (though I guess not necessarily). Some trusted party issues an assertion and says who it's for. The consumer of the assertion makes sure it was intended for them.  This seems is a special case of that where the issuer is also one of the indented audiences.   The SAML draft would allow this situation by allowing for more than one acceptable audience to be included in the token (but you can't do that in JWT). And I'm not aware of anyone actually doing that kind of thing in practice with SAML now. I'm not sure it's the right way to approach it for that matter.

Alternatively the AS could have some special condition on audience validation for tokens that it issued itself. That's a pattern I've heard suggested several times before for various things but, though I can't say exactly why, I've never been real fond of it.

I'm not sure exactly what should be done with the case you describe.

Somewhat tangentally though is that JWT only allows for a single audience to be identified in the token. I've been wondering to myself for some time now if that's too restrictive. Being able to indicated more than one intended audience in a token seems like it would add a lot of flexibility to a number of these various token exchange type scenarios. But then again SAML has that and I don't know how much it gets utilized. So maybe it would just be adding unneeded complexity.

I'm going to stop rambling now...

On Fri, Dec 14, 2012 at 3:40 PM, Justin Richer <jricher at mitre.org<mailto: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<mailto: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<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<mailto:Openid-specs-ab at lists.openid.net>

http://lists.openid.net/mailman/listinfo/openid-specs-ab




_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121215/4319e1ac/attachment-0001.html>


More information about the Openid-specs-ab mailing list