Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences

[Sergey Beryozkin <[e-mail]>]

Hi Brian

Thanks, 'cid' is a proper compact name :-), I've made our code 
configurable - to support reporting a client_id property either as a 
'client_id' or 'cid' claim.

Cheers, Sergey

On 12/08/16 23:30, Brian Campbell wrote:
> Yeah, the client typically isn't the/an audience of an access token. The
> AT is opaque to the client and the client never processes or validates
> it. So aud would have the resource(s) and something else could carry the
> client id.
>
> FWIW, token exchange is looking to define and register "cid" as a JWT
> claim for the client identifier:
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05#section-4.3
>
> On Fri, Aug 12, 2016 at 4:13 AM, Sergey Beryozkin <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi,
>
>
>     After updating my earlier code (where 'client_id' was set as the
>     standard JWT access token 'aud' property) to use 'aud' to represent
>     the resource audiences I'm now thinking how to represent a
>     'client_id' in this token.
>
>     For now if I'm using a 'client_id' claim, to be consistent with a
>     standard token introspection response.
>
>     The other thing is how to represent a name of the user who
>     authorized the code grant which was exchanged for this token.
>
>     Again I'm using a "username" claim, to be consistent with a standard
>     token introspection response.
>
>     Also thinking, what value if any a 'sub' claim in such a token
>     should have. I'm setting it to a unique user identifier (similarly
>     to IdToken).
>
>     Any comments are welcome
>
>     Sergey
>
>
>     On 11/08/16 23:30, Sergey Beryozkin wrote:
>
>         Hi John
>         On 11/08/16 23:24, John Bradley wrote:
>
>             I think most people put the a resource URI in the aud.
>
>             Connect uses the client ID as that is bit more stable than
>             trying to
>             use a redirect URI when there could be multiple ones.
>             Given that a resource server doesn’t typically have a
>             client_id the
>             resource uri make a reasonable value.
>
>             You could put it in resource if you like, but that is
>             probably not
>             what others are doing.
>
>         I was suspecting I might be on my own here yes :-)
>
>
>             It may be time for a interoperable JWT access token profile
>             of some sort.
>
>
>         +1
>
>             We keep getting close with some of the PoP stuff but only
>             specify parts.
>
>
>         Thanks, Sergey
>
>
>             John B.
>
>                 On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin
>                 <[e-mail] <mailto:[e-mail]>>
>                 wrote:
>
>                 Hi All
>
>                 Awhile back I was asking why would self-contained JWS
>                 JWT access
>                 tokens would be used (as opposed to JWE JWTs), my
>                 concern was that
>                 anyone with a JWT library can read this token's content
>                 - but as I
>                 was explained that should not be a problem if such a JWS
>                 JWT token
>                 contains non-sensitive information. Besides, in some
>                 cases, it gives
>                 RS an option to validate this JWS JWT locally, without
>                 having to make
>                 a remote validation call.
>
>                 So I've started experimenting and the immediate question
>                 I have is
>                 this one: which claim should one use to represent a
>                 resource server
>                 audience to get the most inter-operable RS level
>                 validation logic ?
>
>                 For example, a given RS may talk to different 3rd party
>                 authorization
>                 servers, say AS1 (vendor1) and AS2 (vendor2), and either
>                 AS1 or AS2
>                 JWS JWT tokens that this RS validates locally should
>                 ideally use the
>                 same claim to represent a resource audience. RS
>                 validation logic is
>                 written independently (without using AS1 or AS2 aware
>                 validation
>                 libraries).
>
>                 We do expect such requirements coming in our
>                 deployments. AS1 &
>                 independent validation logic is already in use. Just a
>                 matter of time
>                 before AS2 is introduced.
>
>                 So JWT has a standard 'aud' claim - but I believe this
>                 should be a
>                 'clientId' of the client a token is issued to, similarly
>                 to the way
>                 the 'aud' is treated in IdToken.
>
>                 So I've prototyped the code where JWT has these claims:
>
>                 "aud" = clientId
>                 "resource" = 'http://myResourceServer'
>
>                 where 'resource' is borrowed from OAuth2 Resource
>                 Indicators draft
>                 and represent a specific RS target address, the resource
>                 server
>                 audience.
>
>                 Am I on the right path ? How would others do it when
>                 facing a task of
>                 including a resource audience in a self-contained JWS
>                 JWT access token ?
>
>                 Many thanks, Sergey
>
>                 _______________________________________________
>                 OAuth mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/oauth
>                 <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>