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.