[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 22:40:22 UTC 2012
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?
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>>
>> --- you can reply above this line ---
>> Issue 687: Messages - Add 'prn' claim to id_token to support
>> JWT Assertion
>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab