Move all the comparison with Status List in an issue and remove them from the specs

[peppelinux]

All those comparisons will be held in this thread unless an informational RFC will be created about both the status lists and the status assertions

[peppelinux]

OAuth Status Lists [@!I-D.looker-oauth-jwt-cwt-status-list] are suitable for specific scenarios, especially when the Verifier needs to verify the status of a Digital Credential at a later time after the User has presented the Digital Credential.

In scenarios where the Verifier, Credential Issuer, and OAuth Status List Provider are all part of the same domain or operate within a context where a high level of trust exists between them and the End-User, the OAuth Status List is the optimal solution; while there might be other cases where the OAuth Status List facilitates the exposure to the following privacy risks:

• An OAuth Status List Provider might know the association between a specific status list and a Credential Issuer, especially if the latter issues a single type of Digital Credential. This could inadvertently reveal the OAusth Status List Provider information about how a Digital Credential corresponds to a status list.
• A Verifier retrieves an OAuth Status List by establishing a TCP/IP connection with an OAuth Status List Provider. This allows the OAuth Status List Provider to obtain the IP address of the Verifier and potentially link it to a specific Digital Credential type and Credential Issuer associated with that OAuth Status List. A malicious OAuth Status List Provider could use internet diagnostic tools, such as Whois or GeoIP lookup, to gather additional information about the Verifier. This could inadvertently disclose to the OAuth Status List Provider which Digital Credential the requester is using and from which Credential Issuer, information that should remain confidential.

Status Assertions differ significantly from OAuth Status Lists in several ways:

1. Privacy: Status Assertions are designed to be privacy-preserving. Verifier exchanges the Status Assertions directly with the Holder, not requiring the Verifier to gather any additional information from third-party entities. Once a Status Assertion is issued, it can be verified without any further communication with the Credential Issuer or any other party, thus preventing potential privacy leaks.

2. Static Verification: Status Assertions are designed to be statically provided to Verifiers by Wallet Instance.

3. Digital Credentials Formats: Status Assertions are agnostic from the Digital Credential format to which they are bound.

4. Trust Model: Status Assertions operate under a model where the Verifier trusts the Credential Issuer to provide accurate status information, while the OAuth Status Lists operate under a model where the Verifier trusts the Status List Provider to maintain an accurate and up-to-date list of statuses.

5. Offline flow: OAuth Status List can be accessed by a Verifier when an internet connection is present. At the same time, OAuth Status List defines how to download an entire Status List or a Status List Token. In the Status List Token, the status_list and sub members are mandatory. They provide the URL and the index of the revocation entry for the Digital Credential, enabling a Verifier to check the status of the Digital Credential when a broadband connection becomes available. Even if similar to the OAuth Status List Token, the Status Assertions enable the User to persistently use their preexistent Digital Credentials, without disclosing a status URL or any remote reference to it, as long as the linked Status Assertion is available and presented to the Verifier, and not expired.

6. Real-time validation: OAuth Status Lists provide the possibility to do real-time validation of the Digital Credential status. To support the real-time status validation use cases, a Wallet MAY implement strategy to request a new Status Assertion before sending it to the Verifier.

[peppelinux]

other points:

• the bitstring status list hugely increases over time and cannot be reduced, untill all the block will be free, even when the related credential are expired. this creates huge impacts within an it infrastructure

• the Status List URL mixed with the index uniquely identify the credential, representing a sort of super-cookie

[peppelinux]

• communicating the list by the holder (stapling) also forces the holder to disclose new status for credentials the verifier has previously seen or might see in the future

[peppelinux]

A credential is revoked but status list fails download. Is that credential revoked? Standing on the last status list (outdated and already obtained by RP) yes, while it is not.