You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<ahref="#section-5.2" class="section-number selfRef">5.2. </a><ahref="#name-status-list-token-in-cwt-fo" class="section-name selfRef">Status List Token in CWT Format</a>
1952
1952
</h3>
1953
-
<pid="section-5.2-1">The Status List Token <spanclass="bcp14">MUST</span> be encoded as a "CBOR Web Token (CWT)" according to <span>[<ahref="#RFC8392" class="cite xref">RFC8392</a>]</span>.<ahref="#section-5.2-1" class="pilcrow">¶</a></p>
1953
+
<pid="section-5.2-1">The Status List Token <spanclass="bcp14">MUST</span> be encoded as a "CBOR Web Token (CWT)" according to <span>[<ahref="#RFC8392" class="cite xref">RFC8392</a>]</span>. The Status List Token <spanclass="bcp14">MUST</span> not be tagged with the tags defined in section 6 of <span>[<ahref="#RFC8392" class="cite xref">RFC8392</a>]</span> or in section 2 of <span>[<ahref="#RFC9052" class="cite xref">RFC9052</a>]</span>.<ahref="#section-5.2-1" class="pilcrow">¶</a></p>
1954
1954
<pid="section-5.2-2">The following content applies to the protected header of the CWT:<ahref="#section-5.2-2" class="pilcrow">¶</a></p>
<pid="section-5.2-8">The following is a non-normative example of a Status List Token in CWT format in Hex:<ahref="#section-5.2-8" class="pilcrow">¶</a></p>
<ahref="#section-12.3" class="section-number selfRef">12.3. </a><ahref="#name-observability-of-relying-pa" class="section-name selfRef">Observability of Relying Parties</a>
2812
2810
</h3>
2813
-
<pid="section-12.3-1">Once the Relying Party receives the Referenced Token, the Relying Party can request the Status List through the provided <code>uri</code> parameter and can validate the Referenced Token's status by looking up the corresponding <code>index</code>. However, the Relying Party may persistently store the <code>uri</code> and <code>index</code> of the Referenced Token to request the Status List again at a later time. By doing so regularly, the Relying Party may create a profile of the Referenced Token's validity status. This behaviour may be intended as a feature, e.g. for an identity proofing (e.g. Know-Your-Customer process in finance industry) that requires regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of an employee credential.<ahref="#section-12.3-1" class="pilcrow">¶</a></p>
2811
+
<pid="section-12.3-1">Once the Relying Party receives the Referenced Token, the Relying Party can request the Status List through the provided <code>uri</code> parameter and can validate the Referenced Token's status by looking up the corresponding <code>index</code>. However, the Relying Party may persistently store the <code>uri</code> and <code>index</code> of the Referenced Token to request the Status List again at a later time. By doing so regularly, the Relying Party may create a profile of the Referenced Token's validity status. This behaviour may be intended as a feature, e.g. for an identity proofing (e.g. Know-Your-Customer process in finance industry) that requires regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of an employee credential.<ahref="#section-12.3-1" class="pilcrow">¶</a></p>
2814
2812
<pid="section-12.3-2">This behaviour could be mitigated by:<ahref="#section-12.3-2" class="pilcrow">¶</a></p>
<pid="section-12.8-1">As previously explained, there is the potential risk of observability by Relying Parties (see <ahref="#privacy-relying-party" class="auto internal xref">Section 12.3</a>) and Outsiders (see <ahref="#privacy-outsider" class="auto internal xref">Section 12.4</a>). That means that any Status Type that transports information beyond the routine statuses VALID and INVALID about a Referenced Token can leak information to other parties. This document defines one additional Status Type with "SUSPENDED" that conveys such additional information, but in practice all statuses other than VALID and INVALID are likely to contain information with privacy implications.<ahref="#section-12.8-1" class="pilcrow">¶</a></p>
2908
-
<pid="section-12.8-2">A concrete example for "SUSPENDED" would be a driver's license, where the digital driver's license might still be useful to prove other information about its holder, but suspended could signal that it should not be considered valid in the scope of being allowed to drive a car. This case could be solved by either introducing a special status type, or by revoking the Referenced Token and re-issuing with changed attributes. For such a case, the status type suspended might be dangerous as it would leak the information of a suspended driver's license even if the driver's license is used as a mean of identification and not in the context of driving a car. This could also allow for the unwanted collection of statistical data on the status of driver's licenses.<ahref="#section-12.8-2" class="pilcrow">¶</a></p>
2909
-
<pid="section-12.8-3">Ecosystems that want to use other Status Types than "VALID" and "INVALID" should consider the possible leakage of data and profiling possibilities before doing so and evaluate if revocation and re-issuance might a better fit for their use-case.<ahref="#section-12.8-3" class="pilcrow">¶</a></p>
2906
+
<pid="section-12.8-2">Ecosystems that want to use other Status Types than "VALID" and "INVALID" should consider the possible leakage of data and profiling possibilities before doing so and evaluate if revocation and re-issuance might a better fit for their use-case.<ahref="#section-12.8-2" class="pilcrow">¶</a></p>
0 commit comments