Brian
Apologies for any confusion. I agree with you totally.
I was trying to say the pointer is necessary for tls infrastructure agility.
I disagreed with Dominick in this case. The supposed complexity reflects real
world variability we have to deal with in both browsers and serverless cloud
infrastructure components.
That said Dominick I agree with the principle that optionality often creates
complexity and security risks.
Phil
> On Feb 14, 2019, at 3:08 PM, Brian Campbell <bcampb...@pingidentity.com>
> wrote:
>
> Maybe I'm wrong here (it's never out of the question) but based on this
> previous message and this one I believe that actually you are both in favor
> (generally anyway) of the proposal with the optional "mtls_endpoints"
> parameter. While I believe that the comment about optionality and complexity
> was meant to be a more general remark. While I can certainly appreciate a
> desire to keep things simple, I do regret that this thread took a turn
> towards personal. Whether it was the intent or not, there's an impact.
>
>
>
>> On Thu, Feb 14, 2019 at 10:20 AM Phil Hunt <phil.h...@oracle.com> wrote:
>> I feel I have to disagree. I agree that optionality is often complexity and
>> should be avoided. But, I think the optionality here is an agility feature
>> allowing mtls to work across a diversified market of different types of tls
>> terminators with varying capability. Lack of appropriate discovery/options
>> could serve to make the spec unusable in many cases.
>>
>> A complicating factor with tls is that a tls layer failure prevents the AS
>> from issuing a correcting directive like an http error or http redirect.
>>
>> We have to be sure not to break existing clients so we may in some cases
>> need mtls only endpoints. I am not far enough along to know for sure. But I
>> tend to agree with Brian on this.
>>
>> This may be a sign we need more implementation data (including from tls wg)
>> to make the right call.
>>
>> Phil
>>
>>> On Feb 14, 2019, at 8:56 AM, Dominick Baier <dba...@leastprivilege.com>
>>> wrote:
>>>
>>> Sorry - this was not meant to be snide at all.
>>>
>>> It was honest feedback that you also need to keep software complexity in
>>> mind when creating a spec. Every MAY or OPTIONAL, or do it like this OR
>>> that, or send values in arbitrary order adds to complexity. Complexity is
>>> the natural enemy of security.
>>>
>>> Cheers
>>> ———
>>> Dominick
>>>
>>>> On 13. February 2019 at 20:39:16, Richard Backman, Annabelle
>>>> (richa...@amazon.com) wrote:
>>>>
>>>> The issue is that the proposal violates the standard by changing the
>>>> semantics of a parameter it defines. We should be very, very, VERY careful
>>>> about telling implementers to violate an existing standard.. This change
>>>> might prove incompatible with existing or future implementations of 8414,
>>>> it might not, but by violating the standard the proposal creates an
>>>> opportunity for incompatibility that didn’t exist before.
>>>>
>>>>
>>>>
>>>> As far as simplicity is concerned, I find a solution that reuses the
>>>> existing data model and naturally supports existing and future extensions
>>>> to be far simpler than one that introduces ambiguous semantics to existing
>>>> parameters. Generally speaking, data models with properties that mean
>>>> different things in different contexts tend to be fragile and require more
>>>> complex code to work with. But that’s just my experience as, you know, an
>>>> actual developer.
>>>>
>>>>
>>>>
>>>> Let’s keep the assumptions and snide remarks about others’ backgrounds off
>>>> the list, please.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Annabelle Richard Backman
>>>>
>>>> AWS Identity
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: Dominick Baier <dba...@leastprivilege.com>
>>>> Date: Wednesday, February 13, 2019 at 4:18 AM
>>>> To: "Richard Backman, Annabelle" <richa...@amazon.com>, Filip Skokan
>>>> <panva...@gmail.com>
>>>> Cc: Brian Campbell <bcampb...@pingidentity.com>, "Richard Backman,
>>>> Annabelle" <richa...@amazon.com>, oauth <oauth@ietf.org>
>>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery
>>>>
>>>>
>>>>
>>>> I am for keeping it simple and not introducing another link to follow.
>>>>
>>>>
>>>>
>>>> I sometimes wonder how many of the spec authors are actually developers -
>>>> these suggestions make software unnecessary complex ;)
>>>>
>>>>
>>>>
>>>> ———
>>>>
>>>> Dominick
>>>>
>>>>
>>>>
>>>> On 13. February 2019 at 12:25:13, Filip Skokan (panva...@gmail.com) wrote:
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> Additionally, a metadata document that omits token_endpoint in favor of
>>>> mtls_endpoints since only mTLS is supported would violate 8414, as 8414
>>>> says token_endpoint “is REQUIRED unless only the implicit grant type is
>>>> supported.”
>>>>
>>>>
>>>> mtls only AS doesn't get anything out of using mtls_endpoints, its use
>>>> should not be recommended for such AS and regular endpoints will be used,
>>>> this satisfies the requirement
>>>>
>>>> Here is one example, based on my understanding of the “straw man” format
>>>> presented in this thread: RFC8414 defines the value of
>>>> token_endpoint_auth_methods_supported as a “JSON array containing a list
>>>> of client authentication methods supported by this token endpoint.” If
>>>> that array contains “tls_client_auth” and the endpoint specified in
>>>> token_endpoint does not support mTLS, then that metadata violates 8414.
>>>> You could address this by adding a token_endpoint_auth_methods_supported
>>>> parameter to the mtls_endpoints object, and likewise for the other
>>>> endpoints and auth methods. If you take that to its logical conclusion,
>>>> you end up with a complete metadata document hanging off of
>>>> mtls_endpoints. It’s that line of thought that led me to suggest just
>>>> pointing to an alternate document.
>>>>
>>>>
>>>> Assuming we go with using the same root auth methods property, what's the
>>>> issue? Clients not having mtls capabilities won't care about the
>>>> additional method members being present. Clients that do implement mtls by
>>>> the specification will know to look for mtls_endpoints and fall back to
>>>> regular ones if the specific endpoint or mtls_endpoints root property is
>>>> not present.
>>>>
>>>>
>>>>
>>>> I gave `mtls_alternate_metadata` route a thought and don't see how it
>>>> helps, given the two above are non-issues (my $.02) another discovery
>>>> document only brings more of them since every property can now be
>>>> different, not just the endpoints.
>>>>
>>>>
>>>>
>>>> S pozdravem,
>>>> Filip Skokan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle
>>>> <richa...@amazon.com> wrote:
>>>>
>>>> Here is one example, based on my understanding of the “straw man” format
>>>> presented in this thread: RFC8414 defines the value of
>>>> token_endpoint_auth_methods_supported as a “JSON array containing a list
>>>> of client authentication methods supported by this token endpoint.” If
>>>> that array contains “tls_client_auth” and the endpoint specified in
>>>> token_endpoint does not support mTLS, then that metadata violates 8414.
>>>> You could address this by adding a token_endpoint_auth_methods_supported
>>>> parameter to the mtls_endpoints object, and likewise for the other
>>>> endpoints and auth methods. If you take that to its logical conclusion,
>>>> you end up with a complete metadata document hanging off of
>>>> mtls_endpoints. It’s that line of thought that led me to suggest just
>>>> pointing to an alternate document.
>>>>
>>>>
>>>>
>>>> Additionally, a metadata document that omits token_endpoint in favor of
>>>> mtls_endpoints since only mTLS is supported would violate 8414, as 8414
>>>> says token_endpoint “is REQUIRED unless only the implicit grant type is
>>>> supported.”
>>>>
>>>>
>>>>
>>>> It is possible to define the mtls_endpoints parameter such that the above
>>>> use cases are invalid, but that does make the document more complicated..
>>>> If we go the “mtls_alternate_metadata” route, we can skip past all of
>>>> these issues, because it brings us back to just parsing the same metadata
>>>> that we do today.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Annabelle Richard Backman
>>>>
>>>> AWS Identity
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: OAuth <oauth-boun...@ietf.org> on behalf of Filip Skokan
>>>> <panva...@gmail.com>
>>>> Date: Tuesday, February 12, 2019 at 1:13 PM
>>>> To: "Richard Backman, Annabelle" <richanna=40amazon....@dmarc.ietf.org>
>>>> Cc: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org>, oauth
>>>> <oa...@ietf..org>
>>>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery
>>>>
>>>>
>>>>
>>>> Hi Annabelle,
>>>>
>>>>
>>>>
>>>> can you elaborate what would be the violation / negative impact of usage
>>>> of RFC8414?
>>>>
>>>>
>>>>
>>>> As it already makes use of `signed_metadata` and this language is present
>>>> ...
>>>>
>>>>
>>>>
>>>> > Consumers of the metadata MAY ignore the signed metadata if they do not
>>>> > support this feature. If the consumer of the metadata supports signed
>>>> > metadata, metadata values conveyed in the signed metadata MUST take
>>>> > precedence over the corresponding values conveyed using plain JSON
>>>> > elements.
>>>>
>>>>
>>>>
>>>> ... would mtls_endpoints be any different? Clients are free to ignore this
>>>> if they don't support/use mtls, and if they do those values must take
>>>> precedence over the root ones. the use of mtls_endpoints would not be
>>>> recommended for mtls-only AS but recommended for one with both
>>>> mtls/regular authentication methods. token_endpoint remains required for
>>>> all intents and purposes.. And as for the usable client authentication
>>>> methods - they should all be listed, or do you think we should separate
>>>> the ones for each hostname/port location? To what end? Is there a risk
>>>> having the mtls hostname/port accepting regular requests? Other then
>>>> secret/key _jwt auth methods assertion aud claim the endpoint location
>>>> doesn't play a role in the authentication process.
>>>>
>>>>
>>>>
>>>> Best,
>>>> Filip
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle
>>>> <richanna=40amazon....@dmarc.ietf.org> wrote:
>>>>
>>>> I’m not opposed to introducing a metadata change, if the scenario is
>>>> relevant and other approaches can’t adequately address it – and I’ll
>>>> readily grant that we probably don’t want to depend on consistency of
>>>> browser behavior at the intersection of client certificates and
>>>> Access-Control-Allow-Credentials. But care needs to be taken in designing
>>>> that metadata to avoid violating or otherwise negatively impacting usage
>>>> of RFC8414.
>>>>
>>>>
>>>>
>>>> Along those lines, instead of adding an “mtls_endpoints” metadata
>>>> parameter, we could add an “mtls_alternate_metadata” parameter whose value
>>>> is the URL of an alternate metadata document intended for clients using
>>>> mTLS. An mTLS-optional AS could have two different metadata documents for
>>>> mTLS and non-mTLS clients, reducing the mTLS-optional scenario to the
>>>> mTLS-only scenario. This sidesteps the challenges of aligning the
>>>> “either/or” semantics of mTLS-optional with some of the rigid parameter
>>>> definitions in RFC8414 (see: token_endpoint,
>>>> token_endpoint_auth_methods_supported).
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Annabelle Richard Backman
>>>>
>>>> AWS Identity
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: OAuth <oauth-boun...@ietf.org> on behalf of Brian Campbell
>>>> <bcampbell=40pingidentity....@dmarc.ietf.org>
>>>> Date: Tuesday, February 12, 2019 at 10:58 AM
>>>> To: Dominick Baier <dba...@leastprivilege.com>
>>>> Cc: oauth <oauth@ietf.org>
>>>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery
>>>>
>>>>
>>>>
>>>> Thanks for the input, Dominick.
>>>>
>>>>
>>>>
>>>> I'd said previously that I was having trouble adequately gauging whether
>>>> or not there's sufficient consensus to go ahead with the update. I was
>>>> even thinking of asking the chairs about a consensus call during the
>>>> office hours meeting yesterday. But it got canceled. And looking again
>>>> back over the discussion, I don't believe a consensus call is necessary.
>>>> There's been a lot of general discussion over the last several weeks
>>>> during which several folks have stated support for the proposal while
>>>> there's been only one voice of direct dissent. That seems like rough
>>>> enough consensus and, as such, I plan to make the change in the next
>>>> revision of the document (which should be done soon). Chairs, please let
>>>> me know, if you believe the situation warrants a different course of
>>>> action.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier
>>>> <dba...@leastprivilege.com> wrote:
>>>>
>>>> IMHO that’s a reasonable and pragmatic option.
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> ———
>>>>
>>>> Dominick
>>>>
>>>>
>>>>
>>>> On 11. February 2019 at 13:26:37, Brian Campbell
>>>> (bcampb...@pingidentity.com) wrote:
>>>>
>>>> It's been pointed out that the potential issue is not isolated to the just
>>>> token endpoint but that revocation, introspection, etc. could be impacted
>>>> as well. So, at this point, the proposal on the table is to add a new
>>>> optional AS metadata parameter named 'mtls_endpoints' that's value we be a
>>>> JSON object which itself contains endpoints that, when present, a client
>>>> doing MTLS would use rather than the regular endpoints. A straw-man
>>>> example might look like this
>>>>
>>>> {
>>>> "issuer":"https://server.example.com";,
>>>> "authorization_endpoint":"https://server.example.com/authz";,
>>>> "token_endpoint":"https://server.example.com/token";,
>>>> "token_endpoint_auth_methods_supported":[
>>>> "client_secret_basic","tls_client_auth", "none"],
>>>> "userinfo_endpoint":"https://server.example.com/userinfo";,
>>>> "revocation_endpoint":"https://server.example.com/revo";,
>>>> "jwks_uri":"https://server.example.com/jwks.json";,
>>>> "mtls_endpoints":{
>>>> "token_endpoint":"https://mtls.example.com/token";,
>>>> "userinfo_endpoint":"https://mtls.example.com/userinfo";,
>>>> "revocation_endpoint":"https://mtls.example.com/revo";
>>>> }
>>>> }
>>>>
>>>>
>>>>
>>>> A client doing MTLS would look for and give precedence to an endpoint
>>>> under "mtls_endpoints" while falling back to use the normal endpoint from
>>>> the top level of metadata when/if its not in "mtls_endpoints".
>>>>
>>>>
>>>> The idea being that "regular" clients (those not doing MTLS) will use the
>>>> regular endpoints. And only the host/port of the endpoints listed in
>>>> mtls_endpoints will be set up to request TLS client certificates during
>>>> handshake. Thus any potential impact of the CertificateRequest message
>>>> being sent in the TLS handshake can be avoided for all the other regular
>>>> clients that are not going to do MTLS - including and most importantly
>>>> in-browser javascript clients where there can be less than desirable UI
>>>> presented to the end-user..
>>>>
>>>>
>>>>
>>>> I'm struggling, however, to adequately gauge whether or not there's
>>>> sufficient consensus to go ahead with the update. There's been some
>>>> support for it voiced. As well as talk of other approaches that could be
>>>> alternatives or additional measures. And also some vocal opposition to it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dba...@leastprivilege.com>
>>>> wrote:
>>>>
>>>> We are currently implementing MTLS in IdentityServer.
>>>>
>>>>
>>>>
>>>> Our approach will be that we’ll offer a separate token endpoint that
>>>> supports client certs. Are you planning on adding an official endpoint
>>>> name for discovery? Right now we are using “mtls_token_endpoint”.
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> ———
>>>>
>>>> Dominick
>>>>
>>>>
>>>>
>>>> On 7. February 2019 at 22:36:55, Brian Campbell
>>>> (bcampbell=40pingidentity....@dmarc.ietf.org) wrote:
>>>>
>>>> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good
>>>> reminder that even a seemingly innocuous change that should be backwards
>>>> compatible can break things unexpectedly..
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle
>>>> <richa...@amazon.com> wrote:
>>>>
>>>> The case I’m referencing didn’t specifically involve AS metadata. We had
>>>> clients in the wild that assumed that all the properties in the JSON
>>>> object returned from our userinfo endpoint were scalar strings. This broke
>>>> when we introduced a new property whose value was a JSON object. It was a
>>>> good reminder that even a seemingly innocuous change that should be
>>>> backwards compatible can force more work on clients than we expect.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Annabelle Richard Backman
>>>>
>>>> AWS Identity
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: Brian Campbell <bcampb...@pingidentity..com>
>>>> Date: Wednesday, February 6, 2019 at 11:30 AM
>>>> To: "Richard Backman, Annabelle" <richanna=40amazon....@dmarc.ietf.org>
>>>> Cc: "Richard Backman, Annabelle" <richa...@amazon.com>, oauth
>>>> <oauth@ietf.org>
>>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
>>>> clients using the token endpoint
>>>>
>>>>
>>>>
>>>> And I'm honestly really struggling to see what could have gone wrong with
>>>> or how token_endpoint_auth_methods broke something with the user info
>>>> endpoint. If you have the time and/or it'd be informative to this here
>>>> little discussion, please explain that one a bit more.
>>>>
>>>>
>>>>
>>>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell
>>>> <bcampb...@pingidentity.com> wrote:
>>>>
>>>> "far" should have said "fair" in the previous message
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampb...@pingidentity.com>
>>>> wrote:
>>>>
>>>> It may well be due to my own intellectual shortcomings but these
>>>> issues/questions/confusion-points are not resonating for me as being
>>>> problematic.
>>>>
>>>>
>>>>
>>>> The more general stance of "this isn't needed or worth it in this
>>>> document" (I think that's far?) is being heard though.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle
>>>> <richanna=40amazon....@dmarc.ietf.org> wrote:
>>>>
>>>> (TL;DR: punt AS metadata to a separate draft)
>>>>
>>>> AS points #1-3 are all questions I would have as an implementer:
>>>>
>>>> Section 2 of RFC8414 says token_endpoint “is REQUIRED unless only the
>>>> implicit grant type is supported.” So what does the mTLS-only AS put here?
>>>> The claims for these other endpoints are OPTIONAL, potentially leading to
>>>> inconsistency depending on how #1 gets decided.
>>>> The example usage of the token_endpoint_auth_methods property given
>>>> earlier is incompatible with RFC8414, since some of its contents are only
>>>> valid for the non-mTLS endpoints, and others are only valid for the mTLS
>>>> endpoints. Hence this question.
>>>> This introduces a new metadata property that could impact how other specs
>>>> should extend AS metadata. That needs to be addressed.
>>>>
>>>>
>>>> I could go on for client points but you already get the point. Though I’ll
>>>> share that #3 is real and once forced me to roll back an update to the
>>>> Login with Amazon userinfo endpoint…good times. 😃
>>>>
>>>>
>>>>
>>>> I don’t necessarily think an AS metadata property is wrong per se, but
>>>> understand that you’re bolting a layer of flexibility onto a standard that
>>>> wasn’t designed for that, and I don’t think the metadata proposal as it’s
>>>> been discussed here sufficiently deals with the fallout from that. In my
>>>> view this is a complex enough issue and it’s for a nuanced enough use case
>>>> (as far as I can tell from discussion? Please correct me if I’m wrong)
>>>> that we should punt it to a separate draft (e.g., “Authorization Server
>>>> Metadata Extensions for mTLS Hybrids”) and get mTLS out the door.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Annabelle Richard Backman
>>>>
>>>> AWS Identity
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: OAuth <oauth-boun...@ietf.org> on behalf of Brian Campbell
>>>> <bcampbell=40pingidentity....@dmarc.ietf.org>
>>>> Date: Monday, February 4, 2019 at 5:28 AM
>>>> To: "Richard Backman, Annabelle" <richanna=40amazon....@dmarc.ietf.org>
>>>> Cc: oauth <oauth@ietf.org>
>>>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
>>>> clients using the token endpoint
>>>>
>>>>
>>>>
>>>> Those points of confusion strike me as somewhat hypothetical or
>>>> hyperbolic. But your general point is taken and your position of being
>>>> anti additional metadata on this issue is noted.
>>>>
>>>>
>>>>
>>>> All of which leaves me a bit uncertain about how to proceed. There seem to
>>>> be a range of opinions on this point and gauging consensus is proving
>>>> elusive for me. That's confounded by my own opinion on it being somewhat
>>>> fluid..
>>>>
>>>>
>>>>
>>>> And I'd really like to post an update to this draft about a month or two
>>>> ago.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Feb 1, 2019 at 5:03 PM 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.
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>> 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
>>>>
>>> _______________________________________________
>>> 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
>
> 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
