JWT aud claim issues
This ticket filed at the request of Mike Jones after the 17-Dec-12 call: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20121217/002699.html
The current definition of aud in JWT limits the claim to having a single value [http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#section-4.1.5 ]. Connect mandates that aud in an ID Token be the OAuth 2.0 client_id of the Client [http://openid.net/specs/openid-connect-messages-1_0-13.html#id_token].
This situation potentially limits the use of the ID token in other contexts. For example, an ID Token can't really be used in an JWT Bearer Assertion (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03) flow back to the issuing AS or to some other entity.
I'm not sure exactly what changes might be in scope for Connect.
I made a proposal to the OAuth WG regarding allowing aud to have more than one value in this thread: http://www.ietf.org/mail-archive/web/oauth/current/msg10285.html
And there's some additional discussion about the subject in general in this thread on the connect list: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20121217/002708.html
Comments (4)
-
-
- changed status to resolved
Fixed
#689- Track JWT change that allows JWTs to have multiple audiences→ <<cset d43287d5d132>>
-
Fixes
#689added caution about unrecognized audiences.→ <<cset f21b475141c4>>
-
Issue
#691was marked as a duplicate of this issue. - Log in to comment
Our sense is that allowing "aud" to be either a string or an array of strings is OK and less invasive than always forcing it to be an array.