Yeah, probably. On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <[email protected]> wrote:
> If we go down the 307 route, shouldn’t it rather be a 308 (permanent) > redirect? It seems unnecessary for the client to keep trying the original > endpoint or have to remember cache-control/expires timeouts. > > — Neil > > On 2 Feb 2019, at 00:03, Richard Backman, Annabelle < > [email protected]> wrote: > > Confusion from the AS’s perspective: > > 1. If I only support mTLS, do I need to include both > token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or > set it to the empty string? > 2. What if I only support mTLS for the token endpoint, but not > revocation or user info? > 3. How do I specify authentication methods for the mTLS token > endpoint? Does token_endpoint_auth_methods apply to both the mTLS and > non-mTLS endpoints? > 4. I’m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled > device_authorization_endpoint under mtls_endpoints? > > > > Confusion from the client’s perspective: > > 1. As far as I know, I’m a public client, and don’t know anything > about mTLS, but the IT admins installed client certs in their users’ > browsers and the AS expects to use that to authenticate me. > 2. My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > 3. My AS metadata parser crashed because it didn’t expect to encounter > a JSON object as a parameter value. > 4. The mTLS-only AS didn’t provide a value for mtls_endpoints, what do > I do? > 5. I don’t know what that “m” means, but they told me to use HTTPS, so > I should use the one with “tls” in its name, right? > > > > Yes, you can write normative text that answers most of these. But you’ll > have to clearly cover a lot of similar-but-slightly-different scenarios and > be very explicit. And implementers will still get it wrong. The metadata > change introduces opportunities for confusion and failure that do not exist > now, and forces them on everyone who supports mTLS. In contrast, the 307 > redirect is only required when an AS wants to support both, and is > unambiguous in its behavior and meaning. > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Brian Campbell <[email protected]> > *Date: *Friday, February 1, 2019 at 3:17 PM > *To: *"Richard Backman, Annabelle" <[email protected]> > *Cc: *George Fletcher <[email protected]>, oauth <[email protected]> > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients > using the token endpoint > > > > It doesn't seem like that confusing or large of a change to me - if the > client is doing MTLS and the given endpoint is present in `mtls_endpoints`, > then it uses that one. Otherwise it uses the regular endpoint. It gives an > AS a lot of flexibility in deployment options. I personally think getting a > 307 approach deployed and working would be more complicated and error > prone. > > > > It is a minority use case at the moment but there are forces in play, like > the push for increased security in general and to have javascript clients > use the code flow, that suggest it won't be terribly unusual to see an AS > that wants to support MTLS clients and javascript/spa clients at the same > time. > > > > I've personally wavered back and forth in this thread on whether or not to > add the new metadata (or something like it). With my reasoning each way > kinda explained somewhere back in the 40 or so messages that make up this > thread. But it seems like the rough consensus of the group here is in > favor of it. > > > > > > > > > > On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna= > [email protected]> wrote: > > This strikes me as a very prominent and confusing change to support what > seems to be a minority use case. I’m getting a headache just thinking about > the text needed to clarify when the AS should provide `mtls_endpoints` and > when the client should use that versus using `token_endpoint.` Why is the > 307 status code insufficient to cover the case where a single AS supports > both mTLS and non-mTLS? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth <[email protected]> on behalf of Brian Campbell > <[email protected]> > *Date: *Friday, February 1, 2019 at 1:31 PM > *To: *George Fletcher <[email protected] > <[email protected]>> > *Cc: *oauth <[email protected]> > *Subject: *Re: [OAUTH-WG] MTLS and in-browser clients using the token > endpoint > > > > Yes, that would work. > > > > On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch= > [email protected] <[email protected]>> wrote: > > What if the AS wants to ONLY support MTLS connections. Does it not specify > the optional "mtls_endpoints" and just use the normal metadata values? > > On 1/15/19 8:48 AM, Brian Campbell wrote: > > It would definitely be optional, apologies if that wasn't made clear.. > It'd be something to the effect of optional for the AS to include and > clients doing MTLS would use it when present in AS metadata. > > > > On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <[email protected]> > wrote: > > I'm in favour of the `mtls_endpoints` metadata parameter - although it > should be optional. > > > *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 > > [email protected] > > https://www.ietf..org/mailman/listinfo/oauth > <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.* > > > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Brian Campbell Distinguished Engineer [email protected] w: +1 720.317.2061 c: +1 303.918.9415 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter logo] <https://twitter.com/pingidentity> [image: facebook logo] <https://www.facebook.com/pingidentitypage> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo] <https://plus.google.com/u/0/114266977739397708540> [image: Blog logo] <https://www.pingidentity.com/en/blog.html> <https://4.pingidentity.com/WB-2019.2.27apiinnovators_lpWebinarRegistration..html?utm_medium=webinar&utm_source=Direct%20to%20Website&utm_campaign=WB-2019.2.27apiinnovators-WEB> -- _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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
