From discussion in F2F meeting today, we have a few goals:

• No silent information disclosure (eg. can't reveal no matching credential as distinct from user cancelled)
• Developers have a path to diagnose deployment issues

Our conclusions were:

• Most errors will come from the higher level protocol. In that case the wallet should return a protocol-specific object describing the error and the API will technically be a success. It's up to the wallet to ensure whatever information returned fits with their privacy model based on what consent has been collected from the user.
• We will have a few errors at our API level. Once the user has given permission to share a credential, we believe it's OK for us to reveal to the verifier whether there was a matching credential or not (even though they may not have provided consent to the wallet to share any information in particular).
• We want to re-use existing DOMException error names and don't believe it should be necessary to define any new ones.
• Wallets will also have the ability to just return a "user cancelled" error which will just return to the credential selector screen.

So the work now is probably twofold:

1. Add spec text (or a note) that describes that API success doesn't necessarily. mean a credential is being returned - there may be a protocol error.
2. Identify appropriate errors for the API to return.