Add a section on wallet presentation with advice for wallet implementers

[dlongley]

We should add a section to this spec with advice for wallet implementers on presentation.

Specifically, the section should at least include advice along these lines:

Wallets can receive and store VCs that include proofs that are not understood by the wallet, however, these proofs should never be presented by the wallet. A VC with several proofs, some of which the wallet understands and others that it does not, can be presented by the wallet provided that the proof of choice is understood by the wallet and the others are removed prior to presentation. Wallets should maintain allow lists of understood proofs, ensure that any proofs not present are stripped prior to presentation.

Wallets can use the presence of unknown proofs as potential adoption signals in a decentralized ecosystem. It is also important for implementers to understand that in the three party model, the wallet acts as a conduit between the issuer and the verifier, enabling interoperability between the two even if/when the wallet doesn't necessarily implement verification of certain proofs. As an example in another space: "Web browsers were able to download and store PDF files prior to adding their own PDF-reader functionality" -- this kind of decentralized innovation, interoperability, and progressive enhancement is important in the three party model and scalable decentralized ecosystems generally. It is also important to help reduce centralization by not forcing users to necessarily adopt a new wallet just to store a VC that has at least one proof on it that their current wallet does not (yet) understand.

Some proofs may be presentable by the wallet even if the wallet cannot verify them, but this must be understood with certainty, not guessed (i.e., even if a wallet does not add software to verify particular proofs from an issuer when the VC is stored in a wallet, it cannot present such a proof unless it is known that it is safe to do so). As an example, a wallet that can verify an ecdsa-rdfc-2019 proof, but not an ecdsa-jcs-2019 proof can still present either. Other proofs, such as those that offer selective disclosure and / or unlinkability features require transformation (i.e., base proof => derived proof w/ "reveal document") and, therefore, a wallet will not be able to present these proofs unless the wallet has implemented the derived proof procedures. It is vital that a wallet not present a "base proof" by accident, as it may include information that is secret to the holder.

[msporny]

The group discussed this on the 2024-11-19 telecon:

@dlongley explained the issue -- effectively wallets shouldn't present proofs that they don't understand. Wallet implementers need to be warned that they don't have to throw out proof types they don't know, but at the same time, they shouldn't present proofs they don't understand. Proofs that are not understood should never be presented (e.g. base proofs for BBS). @jandrieu asked why the proofs need to be stripped -- @dlongley said that the information might be private to the individual and the "user agent" needs to do a good job of protecting the holder's PII. @jandrieu is concerned that this will result in a user's data rights being infringed upon. @msporny noted that we need to find the right balance of respecting user data rights and right to leave a system and not accidentally allowing transmission of private keys. @TallTed noted that being able to transmit anything does not equate to being required to transmit everything -- restrictions exist for a reason (dangers posed to individuals).

A PR should be raised that instructs wallet implementers that they must not include a proof that they do not understand in a presentation.