Agreed.
> On 20 Feb 2019, at 23:09, John Bradley <ve7...@ve7jtb.com> wrote: > > I agree. > > If someone really wants separate meta-data nothing stops them from having a > separate AS with its own meta-data. > > John B. > >> On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote: >> +1 for defining an optional mtls endpoints section >> >> I first leaned towards a second metadata file, mainly due to the potential >> token endpoint authentication method issue. But adding a secondary metadata >> configuration just for this purpose seems a bit over engineered and would >> take a lot of normative language to get it right. Just as an example: does >> the second configuration overload or replace the primary one? On the other >> hand, any client using looking for mtls based token endpoint authentication >> methods must be aware of the potential mtls endpoints section. So I think >> their is no real issue. >> >> Am 20.02.2019 um 17:59 schrieb Filip Skokan <panva....@gmail.com>: >> >>> +1, great summary >>> >>> Odesláno z iPhonu >>> >>> 20. 2. 2019 v 16:10, Brian Campbell >>> <bcampbell=40pingidentity....@dmarc.ietf..org>: >>> >>>> The objective is to allow the AS to provide MTLS negotiating endpoints on >>>> a different host and/or port so that any non-desirable side effects of >>>> requesting client certificates during the TLS handshake can be avoided for >>>> 'regular' clients that are not doing >>>> any MTLS. >>>> >>>> In all likelihood, I'd expect that any pair of MTLS and regular endpoints >>>> have the same application logic behind them. And that just the TLS setup >>>> that differs to accommodate the aforementioned objective. That means that >>>> they'd support the same client authentication methods but the MTLS >>>> endpoint would just be set up so as to get MTLS to work. When first >>>> considering it, that seemed a bit overreaching for the spec to come out >>>> and say and more of a deployment thing for the AS. But maybe being more >>>> prescriptive would reduce some of the professed problematic ambiguity. As >>>> mentioned in a previous message, referring to the mtls endpoints as >>>> aliases might be useful in indicating that they are the same endpoint that >>>> is just known and accessed differently based on the context of use. >>>> >>>> I'll grant that some of the wording in RFC 8414 can be awkward with >>>> respect to this kind of extension. Calling it a violation is a bit over >>>> the top though. And as much as we might try to write specs that are the >>>> final word, there's the realities of how usage and understanding unfold in >>>> practice. As one example, there's some discussion of the treatment of some >>>> of the metadata in this section of a blog post about a different spec >>>> being developed >>>> https://medium.com/@darutk/ciba-a-new-authentication-authorization-technology-in-2019-explained-by-an-implementer-d1e0ac1311b4#8a00.. >>>> Maybe that's in violation of RFC 8414 or RFC 7591. Or maybe it's being >>>> pragmatic in the given circumstances. I suppose opinions will differ. >>>> >>>> It turns out that writing these specifications is >>>> kinda hard. Even when people share the same objective (and >>>> that's often not even the case), opinions can differ about what actually >>>> constitutes simplicity. It seems that's where we are now. >>>> >>>> My stance as an individual is that the mtls_endpoints (or >>>> mtls_endpoint_aliases) approach is reasonable and pragmatic and the most >>>> straightforward and simple of the options put forth (i.e.. vs a metadata >>>> parameter linking to or well-known locations to completely separate >>>> metadata documents). As an editor, I acknowledge that there's been >>>> disagreement about it while also noting again that the dissenting voices >>>> come from a vocal minority of a few individuals. >>>> >>>> >>>> >>>> >>>>> On Mon, Feb 18, 2019 at 2:55 PM Richard Backman, Annabelle >>>>> <richanna=40amazon....@dmarc.ietf.org> wrote: >>>>> Neil’s example demonstrates how the mtls_endpoints approach leads to >>>>> confusion. Consider the following metadata fragment: >>>>> >>>>> >>>>> >>>>> { >>>>> >>>>> “token_endpoint”: “https://as.example..com/token”, >>>>> >>>>> “token_endpoint_auth_methods_supported”: [ “client_secret_basic”, >>>>> “tls_client_auth” ], >>>>> >>>>> “mtls_endpoints”: { >>>>> >>>>> “token_endpoint”: “https://as.example.com/mtls/token” >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> Which of these statements about endpoints on https://as.example.com/ are >>>>> true? >>>>> >>>>> The /token endpoint only supports client_secret_basic, and /mtls/token >>>>> only supports tls_client_auth. >>>>> The /token endpoint supports both methods, and /mtls/token only supports >>>>> tls_client_auth. >>>>> Both /token and /mtls/token support both methods. >>>>> >>>>> >>>>> All of these could be reasonable interpretations of this metadata. When >>>>> properties mean different things in different contexts, ambiguity abounds. >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Annabelle Richard Backman >>>>> >>>>> AWS Identity >>>>> >>>>> >>>>> >>>>> >>>> >>>> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
