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
<mailto:panva...@gmail.com>>:
+1, great summary
Odesláno z iPhonu
20. 2. 2019 v 16:10, Brian Campbell
<bcampbell=40pingidentity....@dmarc.ietf..org
<mailto: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
<mailto: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
<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/ <https://as.example.com/> are true?
1. The /token endpoint only supports client_secret_basic, and
/mtls/token only supports tls_client_auth.
2. The /token endpoint supports both methods, and /mtls/token
only supports tls_client_auth.
3. 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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
