Thanks for the explanation, Brian. I think the draft’s current structure helped
me to erroneously conflate the two aspects of the document — in that it sounded
like mTLS client authentication was required for an mTLS-bound (or really,
certificate-bound) token. I see now that this isn’t the case,
Hi Justin,
thanks for reviewing the draft.
> Am 01.08.2017 um 21:57 schrieb Brian Campbell :
>
> Thanks Justin.
>
> In my original announcement email, I should have given credit to Torsten as
> he made many of the updates in -03. So complements on improvements as well as
> blame for issues
A fair suggestion and we'll see what can be done to make the distinction
more clear.
On Wed, Aug 2, 2017 at 2:02 AM, Vladimir Dzhuvinov
wrote:
> In terms of structure, I would like to suggest giving PKI bound auth and
> pub key bound mTLS auth their own sections, instead of having them in
> one
In terms of structure, I would like to suggest giving PKI bound auth and
pub key bound mTLS auth their own sections, instead of having them in
one section (2.1 as it is now).
The two methods are distinctive enough, and implementers should easily
recognise they can implement just one of them.
Vlad
I agree with Brian on the points about the difference between validating the
certificate at the AS for client authentication and the RS. This was defiantly
intentional.
Lets face it people do a crap job of validating certificates in general. While
browsers validating TLS certificates is no
Thanks Justin.
In my original announcement email, I should have given credit to Torsten as
he made many of the updates in -03. So complements on improvements as well
as blame for issues can be pointed to him as well!
Your point about document structure is taken and we will look to make the
separa
Brian, thanks for the update. This is really coming along!
I think the spec would benefit from a more clear separation of the client
authentication and resource access sections. They’re really almost two
different but related specs, but there’s enough overlap that I think that
keeping them in t
