[Openid-specs-ab] [openid/connect] Messages - Add 'prn' claim to id_token to support JWT Assertion (issue #687)
Brian Campbell
bcampbell at pingidentity.com
Tue Dec 18 23:22:44 UTC 2012
And it's not even an argument (yet anyway).
Basically I've only just proposed that JWT be relaxed/amended to
consider exactly what you've done to be standardized.
On Tue, Dec 18, 2012 at 4:19 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> Thanks. This is an actual JWT technical issue being considered at present,
> so your implementation/usage experience would be highly pertinent at this
> juncture.
>
>
>
> Thanks,
>
> -- Mike
>
>
>
> From: Dale Olds [mailto:olds at rbcon.com] On Behalf Of Dale Olds
> Sent: Tuesday, December 18, 2012 3:18 PM
> To: Mike Jones
> Cc: Brian Campbell; <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)
>
>
>
> Thanks, Mike. I hadn't seen that. I am on the OAuth2 list but rarely feel
> the need to say anything. I'll float my opinion there.
>
> My intent here was not to argue a JWT issue (i didn't think it was an issue)
> but to suggest possible ways to help in resolving oidc use cases.
>
> --Dale
>
> On 12/18/2012 03:00 PM, Mike Jones wrote:
>
> Dale, there’s a thread about adding the “aud”:[list] syntax to JWT on the
> OAuth list (where JWT is actually being defined) right now. See
> http://www.ietf.org/mail-archive/web/oauth/current/msg10285.html. I’d
> suggest joining the list at https://www.ietf.org/mailman/listinfo/oauth and
> sending a note supporting this addition. I’d be sure to point out that
> you’re already using it in practice.
>
>
>
> That would help move the discussion along on that topic.
>
>
>
> Thanks,
>
> -- Mike
>
>
>
> From: openid-specs-ab-bounces at lists.openid.net
> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Dale Olds
> Sent: Tuesday, December 18, 2012 2:38 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)
>
>
>
> Hey Brian,
>
> To your question: yes, regular access tokens. We follow a convention of
> RS.CoarsePermission in defining scopes. So if a user delegated to a client
> authorization to read their openid info, modify their resources on the cloud
> controller, and read users and groups on their behalf -- we *could* combine
> that in single token (not that that's a good idea). The oauth2 scope would
> look like "openid cloud_controller.write scim.read". The JWT access token
> would contain "aud":["openid","cloud_controller","scim"]. Such a token could
> be presented to the oidc /userinfo endpoint, the scim /Users and /Groups
> endpoints, and the cloud_controller endpoints. Each endpoint validates the
> token and verifies that it is in the intended audience list. This approach
> had been quite useful and flexible. The downside is that we are not
> completely insulating the RSs from each other. In our case we never actually
> combine user account management with cloud controller access and since the
> services are all in the same management domain and we felt potential abuse
> was low when sharing access to the openid /userinfo.
>
> IIRC we made some of our implementation choices due to a comment from Mike
> Jones that (from memory) went something like this: while 'aud' or other JWT
> claims are each single claims the J stands for JSON, so an array is a fine
> value. Made sense to me. Therefore our tokens look like your last example of
> "aud":["Dale","Brian"].
>
> --Dale
>
> On 12/17/2012 07:52 AM, Brian Campbell wrote:
>
> You're right Dale, there's nothing that says it can only be a single
> principal. But aud's current definition as a single StringOrURI value does
> mean that identifying more than one principal would have to be done by
> somehow encoding that fact into a single value. Maybe a value that
> represents a group or some delimiter or something. But interpretations of
> that that kind of thing seem likely to be very application specific. And
> some specs might have restrictions/requirements that make that kind of thing
> difficult too - like Connect specifies that the aud of the ID Token be the
> client id of the client/RP.
>
> You say you commonly generate JWTs that have an RS and the AS identified in
> the audience. I assume those are regular access tokens? What does that look
> like?
>
> Trying to explain what I'm thinking a bit more, by way of example, if we
> wanted to produce a JWT that indicated either you or I as an intended
> audience, we'd have to do something like "aud":"DaleOrBrian" or
> "aud":"some-group-identifier" where some-group-identifier indicates a group
> that we both understand and consider ourselves part of.
>
> I'm wondered if this kind of thing is common enough that the JWT should try
> and help accommodate it by allowing for multiple values to be present in the
> aud claim as an array and stating that the consumer of the JWT must identify
> itself with one of those values. So a token sent to either you our I might
> have an audience claim that looks like, "aud":["Dale", "Brian"].
>
>
>
>
> On Sat, Dec 15, 2012 at 1:53 PM, Dale Olds <olds at vmware.com> wrote:
>
> Somewhat tangentally though is that JWT only allows for a single audience to
> be identified in the token.
>
>
>
> On reading Brian's note I reread the 'aud' section in the JWT spec. It is a
> single 'aud' claim but and I don't see it as being limited to a single
> principal. It says the principal processing the token must be identified in
> the claim and that the interpretation is application specific, but I don't
> see a limit of one. It does add a lot of flexibility to specify more than
> one -- which could be good or bad -- and we do so in our implementation. We
> commonly generate JWTs that have an RS and the AS identified in the
> audience. If it could also help in the OIDC cases, I think that could be an
> option. Or did I miss something in the JWT spec?
>
> --Dale
>
>
>
>
> On 12/14/2012 03:11 PM, Brian Campbell wrote:
>
> 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> 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
>
>
>
>
>
>
More information about the Openid-specs-ab
mailing list