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

Torsten Lodderstedt torsten at lodderstedt.net
Thu Dec 27 17:12:21 UTC 2012


I agree with you for the general JWT case, esp. for multi-audience 
access tokens.

What are examples of multiple audiences in id tokens? Given the original 
posting, I assume this might be the client_id and additionally the 
authorization server itself. This would allow the client to use this 
token in the assertion flow. How is the client supposed to control the 
audiences to be included? Or is this determined by the authorization 
server's policy?

regards,
Torsten.

Am 27.12.2012 15:18, schrieb John Bradley:
> I don't think that having multiple audiences for JWT is a bad thing as 
> long as the recipients know what is going on.
>
> If we put it in the spec then people with closely related RS or multi 
> part clients can use it safely.
> We can also include advice that if you get a multi audience bearer 
> token it could be coming from any party listed in the audience as well 
> as the AS.
>
> I am more comfortable discussing the issues and saying when a 
> multi-audiance token may not be appropriate, vs people going around 
> the spec not understanding the issues.
>
> John B.
> On 2012-12-27, at 4:52 AM, Torsten Lodderstedt 
> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>
>> Isn't the obvious alternative to have different tokens with each 
>> having a single audience value? It would at least prevent token abuse 
>> by resource servers (w/o proof of posession).
>>
>> Regards,
>> Torsten.
>>
>> Am 20.12.2012 um 15:29 schrieb John Bradley <ve7jtb at ve7jtb.com 
>> <mailto:ve7jtb at ve7jtb.com>>:
>>
>>> Yes if we have multiple audiences then who the token is issued to is 
>>> probably only useful if there is some sort of proof of possession to 
>>> go along with that.
>>>
>>> Google's use-case for cid could probably be solved with multiple 
>>> audiences, rather than cid as they are not doing any proof of 
>>> possession.
>>>
>>> The thing is that is you receive a token with multiple audiences 
>>> then you need to assume that any of the parties listed as a audience 
>>> might have sent it to you.
>>>
>>> I think that is a easier security concept for most people to get 
>>> there heads around than thinking cid is special somehow without 
>>> proof of possession.
>>>
>>> So I suspect in the end we need multiple audiences and a way of 
>>> doing proof of possession. They are interrelated but not the same.
>>>
>>> John
>>> On 2012-12-20, at 10:50 AM, Brian Campbell 
>>> <bcampbell at pingidentity.com <mailto:bcampbell at pingidentity.com>> wrote:
>>>
>>>> Without some additional authentication or proof, I don't see what 
>>>> "cid" really provides?
>>>>
>>>> My intent only went as far as getting support for multiple 
>>>> audiences into the base JWT spec so there's some flexibility for 
>>>> other types of token exchange use case. I get that it might have 
>>>> implications in Connect but I don't know if they need to be 
>>>> codified yet.
>>>>
>>>> And, at the risk of picking another fight with the gentlemen from 
>>>> Google, I'm not yet convinced that what they've done with "cid" as 
>>>> some kind of intermediate audience claim is something that should 
>>>> be standardized.
>>>>
>>>>
>>>>
>>>> On Tue, Dec 18, 2012 at 6:17 PM, John Bradley <ve7jtb at ve7jtb.com 
>>>> <mailto:ve7jtb at ve7jtb.com>> wrote:
>>>>
>>>>     If we were to allow multiple audiences in a OIDC id_token it
>>>>     raises the question of how a client requests additional
>>>>     audiences and what it means to a client that receives a id
>>>>     token from that contains multiple audiences.
>>>>     There are also UI issues to consider around what consent the
>>>>     user is asked for.
>>>>
>>>>     This overlaps with the google use  case where the requester is
>>>>     identified in a separate claim.
>>>>
>>>>     It may be a useful thing to indicate the actual requester of
>>>>     the JWT when there are multiple audiences.
>>>>
>>>>     Allowing for a client to get a token that can be presented as
>>>>     part of an implicit flow to a third party with them as the
>>>>     audience opens up a security hole.
>>>>
>>>>     I would be OK if we allow multiple audiences in the ID_token
>>>>     where the client ID of the requester is identified, as long as
>>>>     we do not allow tokens with multiple audiences in the implicit
>>>>     flow.
>>>>
>>>>     So the normal case would be aud as a literal and the 'cid' is
>>>>     implicitly the same as 'aud'.
>>>>
>>>>     If 'aud' and 'cid' differ then the 'aud' is an array of one or
>>>>     more values, and cid is the identifier of the token requestor.
>>>>
>>>>     Then the id_token could be used in an assertion flow though I
>>>>     would prefer that cid have some linking to the client making
>>>>     the assertion flow request.  perhaps there is a way to do that
>>>>     using a proof of possession key.
>>>>
>>>>     Without proof of possession it is not really any worse than a
>>>>     single AS with multiple RS via scopes.  The UI at the
>>>>     authorization server is the hardest part.
>>>>
>>>>     You are being asked to grant client X a assertion granting it
>>>>     permission to access service y on host foo.
>>>>
>>>>     The id_token probably needs to contain some sort of scope info
>>>>     for the target AS to make a decision on.
>>>>
>>>>     From a engineering perspective I like it.  From an explaining
>>>>     it perspective it complicates things.
>>>>
>>>>     John B.
>>>>
>>>>
>>>>
>>>>     On 2012-12-18, at 9:01 PM, Brian Campbell
>>>>     <bcampbell at pingidentity.com
>>>>     <mailto:bcampbell at pingidentity.com>> wrote:
>>>>
>>>>     > BTW Justin, I got focused on other aspect of all this and
>>>>     forgot that
>>>>     > I wanted to ask you what (assuming aud and prn/sub/who/etc
>>>>     work out)
>>>>     > this exchange actually looked like? The JWT Assertion is
>>>>     designed for
>>>>     > the case of trading a JWT for an access token but it sounds
>>>>     like you
>>>>     > are using it to get an id token? Is that in place of the
>>>>     access token
>>>>     > or does it supplement it?  Do you send an openid scope in the
>>>>     request?
>>>>     > Just curious really...
>>>>     >
>>>>     > 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/20121227/0981cad1/attachment-0001.html>


More information about the Openid-specs-ab mailing list