On Tue, Apr 07, 2020 at 03:31:09PM -0600, Brian Campbell wrote:
> One of the primary motivations for the proof-of-possession mechanism of
> DPoP being at the application layer was to hopefully enable implementation
> and deployment by regular application developers. A lesson learned from the
>
One of the primary motivations for the proof-of-possession mechanism of
DPoP being at the application layer was to hopefully enable implementation
and deployment by regular application developers. A lesson learned from the
difficulties and lack of adoption around Token Binding was that access to
On Mon, Apr 06, 2020 at 12:05:28PM -0600, Brian Campbell wrote:
> Hi Mike,
>
> Thanks for your interest in the work and review of the draft. As one of the
> too-many authors on the document, I attempt to answer questions and respond
> to comments inline below. Though I admit to not having
I want to add my perspective to the question of audience restriction, below:
One of the problems with implementing audience restriction of RS’s in the wild
has actually turned into a problem of audience identification instead. In other
words, the client needs to know some identifier that the RS
Hi Mike,
Thanks for your interest in the work and review of the draft. As one of the
too-many authors on the document, I attempt to answer questions and respond
to comments inline below. Though I admit to not having necessarily adequate
answers to everything at the ready. And also apologize for
Hi,
Glad to see DPoP moving forward as a working group item.
I have a couple of comments on the current draft:
1.
I recommend expanding the description of the threat model.
It's not entirely clear to me what threats DPoP is expected to address, which
makes it hard to evaluate whether DPoP meets
