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

From: Dave Tonge <[email-masked]>
Date: Tue, 28 May 2019 17:28:54 +0200

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

---

From: George Fletcher <[email-masked]>
Date: Fri, 31 May 2019 14:47:20 -0400

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:
> https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client_assertion-passed-to??(including 
> *
> *
> We are leaning towards requiring the Authorization Server to accept 
> any of the above values, but recommending that the Client use the 
> issuer value.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 31 May 2019 13:54:34 -0600

Yeah, the discussion was/is definitely about "other endpoints at the AS"
like revocation, introspection, device authorization, etc.

On Fri, May 31, 2019 at 12:47 PM George Fletcher <gffletch=
[email-masked]> wrote:

> 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 :)
>
> Full details of the issue are here:??
> 1.??the token endpoint (as RFC7521 says)
> that the issuer value is the one we should recommend that clients use.??
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._