Hi Suhas,
Hereafter is my early feedback.
RFC 9449 states:
The basic flow involves a client obtaining a DPoP-bound token from
an authorization server,
then using that token with an application protocol by providing
proof of *possession* of the associated private key.
There is first a vocabulary problem which is inherent to RFC 9449.
The protocol does not demonstrate the proof of *possession* of the
associated private key
but only that some entity has been able to take benefit of the *use* the
associated private key.
I know that this is rather embarrassing.
I see two ways to address this issue (they may be more).
a) tell that, despite the use of the acronym DPoP, the basic flow
involves a client obtaining a DPoP-bound token from an authorization
server,
and using that token with an application protocol, this
provides a proof of *knowledge* of the associated private key by an
*unknown* entity,
but not a proof of *possession* of the associated private keyby
the entity that *presents* the DPoP-Bound Access Token
+ Application Generic DPoP Proof with Binding Fields to the
"application protocol server".
In this case, this distinction should be added into the
Security Considerations section.
(b) define a flow where a DPoP-bound token can contain additional
information that allows an "application protocol server" to know how
good (or bad)
the private key is associated with the entity that presents
the DPoP-Bound Access Token + Application Generic DPoP Proof with
Binding Fields.
In such a case, the DPoP-Bound Access Token would contain
additional information to carry some characteristics of the client
_*and*_**of its underlying environment.
Such characteristics can indicate that the export of the
private keys is either not allowed or strictly controlled (e.g., for
back-up purposes)
*_and_ *that the use of the private keys is restricted to one or
more trusted applications, e.g., to a set of trusted web browsers.
I did noticed that the Introduction states:
While keeping the first part unchanged, this framework generalizes
the second part to enable proof-of-possession token binding
for various application contexts beyond HTTP while maintaining the
security properties established in RFC 9449.
In case (b), the first part of the flow would also need to be changed.
Denis
Hello All
We will be presenting about our draft
https://www.ietf.org/archive/id/draft-nandakumar-oauth-dpop-proof-00.html
at IETF124 oauth meeting
and would love to get some early feedback on the proposal.
Please let us know
Thanks
Suhas
On Mon, Sep 15, 2025 at 10:58 PM Suhas Nandakumar
<[email protected]> wrote:
Hello All
We submitted a draft introducing a new DPoP-proof designed to
enable the use of sender-constrained tokens across various
application scenarios.
This effort originated from the need to support DPoP within the
Media Over QUIC Transport context and to define a non-HTTP
mechanism for specifying MOQ protocol actions when presenting the
proof.
Draft can be found here:
https://www.ietf.org/archive/id/draft-nandakumar-oauth-dpop-proof-00.html
Look forward to hearing feedback
Cheers
Suhas Nandakumar
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
