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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
