Re: [OAUTH-WG] Client assertions to endpoints other than the token endpoint

So if by "other endpoints" we mean "other endpoints at the AS" then I 
think issuer makes a lot of sense and could be recommended value.

However, if the client assertion is being sent to an endpoint not 
managed by the AS, then it should use a value that identifies that 
"audience". In this case, something more akin to the "resource 
identifier" of the endpoint is probably best. Abeit, that is still a 
very fuzzy definition :)

On 5/28/19 11:28 AM, Dave Tonge wrote:
> Dear OAuth WG
>
> We have an issue that we are discussing in the OIDF MODRNA work group 
> relating to the Client Initiated Back Authentication spec (which is an 
> OAuth 2 extension). As the issue affects the wider OAuth ecosystem we 
> wanted to post it here and gain feedback from the OAuth Working Group.
>
> Full details of the issue are here: 
> https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client_assertion-passed-to??(including 
> a helpful context setting by Brian), but the summary is:
>
> *What audience value should a Client use when using a client assertion 
> (RFC7521) to authenticate at an endpoint other than the token endpoint?*
> *
> *
> The three options we have are:
> 1. the token endpoint (as RFC7521 says)
> 2. the endpoint the assertion is being sent to (e.g. revocation, 
> backchannel)
> 3. the issuer
>
> We are leaning towards requiring the Authorization Server to accept 
> any of the above values, but recommending that the Client use the 
> issuer value.
>
> The reasons for this are:
> 1. All of the above values are arguably valid, so in the interest of 
> interoperability the AS should accept them all.
> 2. We see no clear security benefit to requiring the audience to be 
> the value of the endpoint the assertion is being sent to, and 
> therefore think that the issuer value is the one we should recommend 
> that clients use.
>
> We would be grateful for your feedback on this issue and believe it 
> would be in the best interest of the ecosystem for there to be a 
> consistent approach to this across OAuth 2 extensions and profiles.
>
> Thanks
>
> Dave Tonge
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth