Re: [OAUTH-WG] Client assertions to endpoints other than the token endpoint
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 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
Re: [OAUTH-WG] JWT Response for OAuth Token Introspection - IPR Disclosure
Rifaat, I’m not aware of any IPR regarding https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/. kind regards, Torsten. > Am 31.05.2019 um 14:25 schrieb Rifaat Shekh-Yusef : > > Torsten and Vladimir, > > As part of the shepherd write-up for the JWT Response for OAuth Token > Introspection document, we need an IPR disclosure from you. > > Are you aware of any IPRs related to this document? > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ > > Regards, > Rifaat smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT Response for OAuth Token Introspection - IPR Disclosure
Hello Rifaat, On 31/05/2019 15:25, Rifaat Shekh-Yusef wrote: > Torsten and Vladimir, > > As part of the shepherd write-up for the *JWT Response for OAuth Token > Introspection* document, we need an IPR disclosure from you. > > Are you aware of any IPRs related to this document? > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ No, I'm not aware of any existing IPRs that may pertain to this spec. > Regards, > Rifaat Vladimir -- Vladimir Dzhuvinov smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] JWT Response for OAuth Token Introspection - IPR Disclosure
Torsten and Vladimir, As part of the shepherd write-up for the *JWT Response for OAuth Token Introspection* document, we need an IPR disclosure from you. Are you aware of any IPRs related to this document? https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ Regards, Rifaat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
