At the moment no, The HoK work is ongoing.
If you are talking about using an assertion as a authorization grant the subject should be the resource owner or some proxy for that. In Connect that would be the user_id not the client_id. We have added Authorized party "azp" to connect id_tokens that would be where the client_id of the requester of the token would go. That however is a Connect extension of JWT and not documented as part of assertion processing. One might expect that in some cases the token endpoint might authenticate the client and match the client_id with the value of "azp" for increased security. That can be done now and is a bit like symmetric proof of possession where azp is used as a reference. Once you start crossing trust boundaries things get more complicated as the client probably has different client_id for each AS. So at that point you can't use the client_id and need to probably go to asymmetric proof of possession and trust that the initial assertion in the chain has properly authenticated the client. This needs more work to flesh out. I know Justin is also working on some token chaining proposals. John B. On 2013-02-18, at 7:50 PM, Lewis Adam-CAL022 <adam.le...@motorolasolutions.com> wrote: > > Is there any guidance on the usage of client_id when using the JWT assertion > profile as a grant type? draft-ietf-oauth-jwt-bearer-04 makes no mention so > I assume that it is not required … but it would be necessary if using in > conjunction with a HOK profile where the JWT assertion is issued to – and may > only be used by – the intended client. Obviously this is straight forward > enough, really I’m just looking to be sure that I’m not missing anything. > > tx > adam > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
