That's fair. I'll see if maybe I can piece together some reasonable text
about it and/or will also try to discuss it with the WG this week in
Bangkok.
On Fri, Nov 2, 2018, 3:18 AM John-Mark Gurney I do not have a good enough understanding of OAuth nor how it is used
> in this draft to be able to
Hi John,
I suggest you read the first few sections of the OAuth spec as it may explain
better the use of terms in OAuth as they are a little different due to
implementation. In this case I believe you mean "Resource Owner" as the
"Client"'s certificate is not going to be a privacy issue unless
This sounds like a great thing to add. That this draft should only be
used by clients that have many (in the hundreds, if not thousands)
"natural persons" associated with it, and if not, then you should use
X instead.
On Thu, Nov 1, 2018 at 8:21 AM Nat Sakimura wrote:
>
> Adding to it, in OAuth
I do not have a good enough understanding of OAuth nor how it is used
in this draft to be able to write a proper security considerations
section about it. You mention that the OAuth certification is
different than one for client cert authentication, but as I don't know
the standard well enough, I
Adding to it, in OAuth MTLS setting, the client cert is that of the OAuth
client, which is typically a web server and not of a natural person. The
content of the certs should be well publicized so that the natural person
and the OAuth Authorization Server involved should become aware of what
this c
I believe the standard approach to this is to only prompt for a client
certificate in a renegotiation handshake rather than in the initial handshake.
Renegotiations are encrypted under the existing TLS session.
— Neil
> On 1 Nov 2018, at 14:37, Brian Campbell
> wrote:
>
> To be honest, I tho
To be honest, I thought that was a relatively well known aspect of TLS 1.2
(and prior) and a noted difference of the new features in TLS 1.3. Also,
I'd note that we're well past WGCL for this document. But, with that said,
I suppose adding some privacy considerations text on the subject is
worthwhi
I would suggest that the security considerations section of
draft-ietf-oauth-mtls-12 be expanded to include the privacy
implications of using this on versions of TLS before 1.3. On all
versions of TLS before 1.3, the client cert is not encrypted and can
be used by third parties to monitor and trac
