This text addition proposal results from the split of section 10.1:
10.2. End-User intrackability
Intrackability is a property whereby one or more Issuers are prevented to learn
by which Verifier(s) a SD-JWT that they have issued has been consumed (or will be consumed).
The following types of intrackability are considered here:
End-User intrackability by one Issuer: incapability of an Issuer
alone to learn to which Verifiers a SD-JWT that it has issued
will be presented by a Holder.
End-User intrackability by both Issuers and Verifiers:
incapability of one Issuer, with the help of one Verifier, to
learn by which Verifier a SD-JWT that it has issued has been
consumed.
End-User intrackability by one Issuer is natively supported when using
SD-JWTs since a SD-JWT does not contain an "aud" claim.
End-User intrackability by both Issuers and Verifiers cannot be supported
using SD-JWTs, as soon as a Verifier communicates the SD-JWT either to
an authority upon its request that will then communicate it to the
Issuer or deliberately communicates the SD-JWT to the Issuer.
However, some mechanisms using zero-knowledge proofs (ZKP) may be able
to support this property.
Ii is important to notice, for example, that a national authority can
require to get an access to the audit logs from both a Verifier and
an Issuer to know whether a same SD-JWT has been logged in both files.
Since the Issuer "needs to know its customer" (KYC), national
authorities may be able to identify an End-User who made an access
to a Verifier.
Section 10.X (Storage of User Data) RECOMMENDS that after
verification, Verifiers SHOULD NOT store the SD-JWT. Depending upon
the context of use, this recommendation should or should not be
followed since there exist cases where such property will be non-
desirable in particular to fight against crime or money laundering.
This text addition proposal results from the split of section 10.1: