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= 40aol....@dmarc.ietf.org> wrote: > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://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._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
