> On Mar 28, 2022, at 8:28 AM, Denis <denis.i...@free.fr> wrote:
<snip>
> The primary aim of DPoP is to bind a token to a public key upon
> issuance and requiring that the client proves possession
> of the corresponding private key when using the token. This does not
> demonstrate that the client presenting the token is
> necessarily the legitimate client. In the case of non-collaborating
> clients, DPoP prevents unauthorized or illegitimate parties
> from using leaked or stolen access tokens. In the case of
> collaborating clients, the security of DPoP is ineffective
> (see section 11.X).
>
<snip>
> If a client agrees to collaborate with another client, the
> security of DPoP is no longer effective. When two clients agree to
> collaborate,
> these results of the cryptographic computations performed by one
> client may be communicated to another client.
>
>
If a system has shared its tokens and/or credentials with another system, they
are both operating as part of a single client. Neither DPoP nor OAuth define
how two clients can share access, such as by applying scopes issued against the
client with identifier “foo” to the client with id “bar”.
From an AS or user perspective, multiple parties could collaborate beyond the
expectations and limitations they intended the client to have. However, sharing
across parties or underlying systems could be entirely within expectations -
such as multiple services which together use information from the resource
server to fulfill a request.
One could have text such as:
DPoP does not prevent sharing of data or access by a client with additional
parties which are not authorized by the AS. In particular, a client may
voluntarily share either private keys or constructed DPoP proofs.
But this is somewhat matter-of-factly stating that the AS should continue to
have the same evaluation process of what parties should be given access as
clients - that DPoP is not a DRM or DLP scheme.
<snip>
> Even if the private key used for DPoP is stored in such a way
> that it cannot be exported, e.g., in a hardware or software security module,
> the client can perform all the cryptographic computations needed
> by the other client to create DPoP proofs.
>
This seems unneeded with the text above. In addition, DPoP does not define a
way for an AS to ensure it only issues access tokens against PoP keys which are
non-exportable.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
