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
