For what it’s worth, if we think of things a little bit differently, we can
support both types of key presentation and possession proofs in parallel. My
thinking was that in both the MTLS and DPoP cases, the client proves that it
has access to a key and then uses that key with the RS in the same
Hi Ben,
> I've forgotten the details of those two documents, but in the general case,
> if there's a WG document that is no longer actively being worked on (or is
> now believed to be a bad idea), the chairs can pretty easily get a new rev
> posted that has a "tombstone" notice, like "this docu
Hi Karl,
> On 7. May 2019, at 22:42, Karl McGuinness wrote:
>
> 1) You often need to deploy your cloud edge load balancer in TCP mode and
> handle your own TLS termination if you want client authentication.
I like that option since it gives end2end transport security for your
application. Un
> On May 7, 2019, at 8:12 AM, George Fletcher
> wrote:
>
> To compromise an MTLS bound token the attacker has to compromise the private
> key. To compromise a DPOP bound token, depending on what HTTP request
> elements are signed, and whether the DPOP is managed as one-time-use etc,
> there
1) You often need to deploy your cloud edge load balancer in TCP mode and
handle your own TLS termination if you want client authentication.
2) There are often many intermediates between your edge where client TLS is
terminated and your actual service. You need to forward cert context from the
> Am 07.05.2019 um 20:09 schrieb Karl McGuinness :
>
> mTLS has significant challenges at scale in a multi-tenant SaaS deployment on
> public clouds using modern edge technologies/services. Applications are
> increasingly being built using Function-as-a-Service/ephemeral workloads as
> well.
mTLS has significant challenges at scale in a multi-tenant SaaS deployment on
public clouds using modern edge technologies/services. Applications are
increasingly being built using Function-as-a-Service/ephemeral workloads as
well. Additional complexity increases if you also want to support "b
On Tue, May 07, 2019 at 11:18:21AM -0600, Brian Campbell wrote:
> Practically speaking there's the MTLS draft, which has been sent to the
> IESG for publication, has commercial and opensource implementations as well
> as production deployments, and is referenced by other prospective standards
> and
Hi,
mTLS is dead simple to use, secure, is used and can be used on a broad basis
(in contrast to the token binding stuff). I also like the fact it provides both
client authentication and sender-constraining.
We started the work on DPoP for the simple reason that SPAs don’t work well
with mTLS
Practically speaking there's the MTLS draft, which has been sent to the
IESG for publication, has commercial and opensource implementations as well
as production deployments, and is referenced by other prospective standards
and profiles. It's not uncommon to receive off list inquires about the
docu
George,
> I don't see them the same at all. With MTLS, the token is bound to the
> transport layer (and the key used to establish that encrypted connection).
> With DPOP, the token is bound to the private key known to the client.
Strictly speaking both solutions tie the token to the public key
To clarify, I wasn’t suggesting we drop one or the other. Both have their
merit and use cases, and both should be developed all the way to standard
IMO. But from some preliminary exploration, it seems unlikely that services
will adopt both at the same time. From the “pr” perspective, having a clear
Am 07.05.19 um 16:12 schrieb George Fletcher:
> I don't see them the same at all. With MTLS, the token is bound to the
> transport layer (and the key used to establish that encrypted
> connection). With DPOP, the token is bound to the private key known to
> the client.
They are certainly not the s
I don't see them the same at all. With MTLS, the token is bound to the
transport layer (and the key used to establish that encrypted
connection). With DPOP, the token is bound to the private key known to
the client.
To compromise an MTLS bound token the attacker has to compromise the
private
Hi all,
In the OAuth conference call today Vittorio mentioned that some folks are
wondering whether DPOP is essentially a superset of MTLS and whether it makes
sense to only proceed with one solution rather potentially two.
I was wondering whether others in the group have a few about this aspec
15 matches
Mail list logo
