[Openid-specs-ab] [openid/connect] Messages - Add 'prn' claim to id_token to support JWT Assertion (issue #687)
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.
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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab