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 > <richanna=40amazon....@dmarc.ietf.org> wrote: > > Confusion from the AS’s perspective: > 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? > What if I only support mTLS for the token endpoint, but not revocation or > user info? > 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? > 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: > 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. > My AS metadata parser crashed because the mTLS-only AS omitted > token_endpoint_uri. > My AS metadata parser crashed because it didn’t expect to encounter a JSON > object as a parameter value. > The mTLS-only AS didn’t provide a value for mtls_endpoints, what do I do? > 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 <bcampbell=40pingidentity....@dmarc.ietf.org> > Date: Friday, February 1, 2019 at 3:17 PM > To: "Richard Backman, Annabelle" <richa...@amazon.com> > Cc: George Fletcher <gffle...@aol.com>, oauth <oauth@ietf.org> > 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=40amazon....@dmarc.ietf.org> 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 <oauth-boun...@ietf.org> on behalf of Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> > Date: Friday, February 1, 2019 at 1:31 PM > To: George Fletcher <gffletch=40aol....@dmarc.ietf.org> > Cc: oauth <oauth@ietf.org> > 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=40aol....@dmarc..ietf.org> 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 <dave.to...@momentumft.co.uk> > 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 > 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. > > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
