[OAUTH-WG] Proposed text for a Privacy considerations section in draft-ietf-oauth-dpop-02

[Denis <[e-mail]>]

This is the development of the 18 th comment from my previous email.

Proposed text:

9. Privacy considerations

The document does not specify how the public key used to compute the 
signature of the DPoP proof JWT is generated or comes from. Different 
scenarios are possible.
They are addressed with respect to the ability of RSs or other servers 
being able to link the users using the DPoP proof JWTs and the 
associated access tokens they receive.

In order to limit attacks to impersonation attacks, an access token must 
include either a "sub" claim or other claims allowing to unambiguously 
identify the user to a RS.
When a "sub" claim is being used, RFC 7519 states in section 4.1.2 that 
"the subject value MUST either be scoped to be locally unique in the 
context of the issuer or be globally unique".

When the subject value is globally unique, RSs usually do not learn more 
than they already knew but since that subject value may be shared and 
compared with globally unique identifiers
stored by other servers that are not part of the OAuth framework this 
may be considered as a problem but this has nothing to do with the DPoP 
mechanism.

The case where the subject value is locally unique in the context of the 
AS or other claims incorporated into an access token allow to 
unambiguously identify the user to a RS is addressed below.


9.1 Use of a single asymmetric key pair for all ASs

All the "DPoP" access tokens issued by all the ASs, will include the 
same public key.

When the subject value is locally unique in the context of the issuer 
(i.e. an AS) or other claims allow to unambiguously identify the user to 
a RS,
RSs may learn more than they already knew since a locally unique 
identifier used by one AS may be different from another locally unique 
identifier used by another AS.
The same applies for other claims allowing to unambiguously identify the 
user to a RS. In this case, this allows RSs to link a "sub" claim or 
other claims allowing
to unambiguously identify the user to a RS with another "sub" claim or 
other claims allowing to unambiguously identify the user to another RS.

While this method may not be a problem when it is only used within an 
Intranet context, this method may be a problem as soon as it is used 
over the Internet,
because RSs will be able to link the access tokens they receive. This 
method is strongly deprecated when used over the Internet. It may be 
used with great care
within an Intranet as long as the network is kept isolated from the 
Internet since it may affect the privacy of the users.

9.2 Use of a static asymmetric key pair between a client and each AS

All the "DPoP" access tokens issued by one AS for one user, will include 
the same public key. This allows each RS to know whether the access tokens
it receives are coming from the same AS and from the same user.

Using this method, RSs are able to know that the access tokens they 
receive have been issued for the same user whatever claims have been 
incorporated
into the access token. This method may affect the user's privacy.

9.3 Use of a static asymmetric key pair between a client and each RS

All the "DPoP" access tokens issued for one RS, will include the same 
public key, no matter which AS has generated the access token.
This allows each RS to know that the access tokens it receives are 
coming from the same user. Using this method, RSs are unable to link the 
access tokens
they receive when receiving a DPoP proof JWT.

 From a security point of view, this method has a side benefit since all 
access tokens that contain the same public key that are received by a 
given RS are indeed
issued for the same user.

9.4 Use of an ephemeral asymmetric key pair for every "DPoP" access token

When only using the public key placed in a "DPoP" access token, RSs are 
unable to link the access tokens they receive.  However, this method has 
the disadvantage
to require the generation of a different key pair for every "DPoP" 
access token.  This may be time and resource consuming.  When this 
method is being used,
it is recommended to generate key pairs in advance, whenever it is 
possible.

Denis