[Openid-specs-ab] [openid/connect] Messages - Add 'prn' claim to id_token to support JWT Assertion (issue #687)
Dale Olds
olds at vmware.com
Tue Dec 18 23:17:36 UTC 2012
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
> <mailto: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 <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/20121218/a1b495ea/attachment.html>
More information about the Openid-specs-ab
mailing list