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
