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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to