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

Wed Dec 19 01:59:00 UTC 2012

I would like to amend the definition of 'cid' from token requester to token
assignee, or the licensed/registered user of the token. JWT can be generic
credential without respect to the protocol associated in obtaining it, so
the above definition is better.

Actually, it was my homework to send the 'cid' proposal to OAuth list... I
will do so later today.

Nat

On Wed, Dec 19, 2012 at 10:17 AM, John Bradley <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>
> 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>
> 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>
> 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> 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. 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
> >>>
> >>>
> >>
> >>
> > _______________________________________________
> > Openid-specs-ab mailing list
> > 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121219/2ec2e354/attachment.html>