FYI, I have just posted proposed text for 'cid' in a separate thread. Nat
On Wed, Dec 19, 2012 at 7:14 AM, John Bradley <[email protected]> wrote: > We probably also need to consider this in light of people like Google > already adding new JWT claims to specify a secondary audience, though there > 'cid' Client ID claim is more about who requested the token. > > I am not keen on claims that are sometimes a literal and sometimes an > array, though it works in JSON it can be confusing. > > Are you proposing that aud us always an array with one or more values, or > that it is a literal if it is one value and array if more than one? > > The other way to deal with it is having a abstract audience that all the > recipients recognize. Though that has its own issues. > > Having one way to do it would be better, I just don't have a good feeling > that it is worth complicating the simple case where there is only one > audience. > > I might be convinced of the utility for aud to be an array if you need > mopre than one value and leave the single case as a literal. > > John B. > > On 2012-12-18, at 6:41 PM, Brian Campbell <[email protected]> > wrote: > > WG folks, > > I'm wondering if the current definition of the "aud" (audience) claim in > JWT [1], which limits the value of the claim to a case sensitive string > containing a StringOrURI value, might not be flexible enough? > > In thinking about or discussing various potential applications of JWT, the > possibility of having a token intended for consumption by more than one > entity has come up frequently. One such example would be an AS that is > using JWTs as structured access tokens intended for use at multiple RSs and > wants to audience restrict those access tokens. Doing that with the current > JWT and "aud" claim could be rather awkward in that a single aud value > would need to somehow represent multiple entities, which seems likely to be > done in very application specific ways that would not result in much > interoperability. Scope is potentially applicable in this case but isn't > standardized at that level and wouldn't be useful outside of OAuth specific > applications. > > At a high level, I'm proposing that we consider changing the definition of > "aud" to allow for an array of StringOrURI values. And change the > processing requirement such that the thing consuming the claim must > identify itself with [at least] one of the values of the "aud" claim array. > That would allow a JWT AT that's intended for consumption by RS 1, 2 and 3 > to be audience restricted like this, "aud": ["RS1", "RS2", "RS3"] and an > individual RS just needs to find itself in one of the values of the claim. > > Such a change would add some complexity but I'm beginning to think that > it's a good trade off for the added flexibility it brings. The validation > would be basically the same but just over a list of values rather than > against a single one. We would have to decide whether the case of a single > audience could still be represented as it is now or if everything would > always have to be an array (i.e. "aud": "RS" vs. "aud": ["RS"] ). The > former introduces slightly more complexity to validation but is a nice > optimization for the common case and would preserve compatibility with > existing implementations. > > Thoughts, comments, questions, or angry diatribes? > > Thanks, > Brian > > [1] > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#section-4.1.5 > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
