Add further details of how errors are returned from Browser API including a example error response

[jogu]

As per @awoie comment here https://github.com/openid/OpenID4VP/pull/155/files#r1652002661:

It would make sense to add an error response example as well.

and @marcoscaceres comment here https://github.com/openid/OpenID4VP/pull/155/files#r1660602655:

Errors should probably result in promise rejections, no?

[marcoscaceres]

it would be good to discuss here and in the DC spec itself how we handle particular types of errors and response errors... we need to clarify what's "exceptional" (causing the promise to reject in the browser API), and what's expected as response data when there is some error.

[jogu]

I agree @marcoscaceres - it would probably be good to have a discussion about errors in a WICG call. I had a look and this issue from Rick is probably a place to discuss it: w3c-fedid/digital-credentials#130

We may also need to update the example javascript call to the digital credential API in the VP spec depending on the outcome.

[Sakurann]

discussed during the WG call:

• we need to clearly define how error codes currently defined in https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-6.4 are returned in the openid4vp response over the browser API. Current assumption is as members in the JS object.
• need examples for the above.
• out of the error codes defined in section 6.4, some probably don't apply in browser API profile, or can be used in both, like invalid_request? -> parallel discussion happening in W3C.
• need a separate discussion if which error codes should not be returned from privacy perspective are different between vanilla openid4vp and browser api profile. -> please open a separate issue on this.

[jogu]

I think wallet implementations are currently behaving inconsistently here, so I do think we need to clarify this.

It is definitely expected that an error before the user has actually selected a credential to return will result in an exception that has no detail (to avoid leaking any information without user interaction).

Once the user has selected a credential there's definitely an argument that a more detailed error can be returned. At least in the current Android implementation my understanding is that the only way to return a more detailed error to the verifier/caller is to return it in the same way you would return a successful response, i.e. the DC API would return a Credential object where data contains a OID4VP response that has error & potentially error_description.

[jogu]

This is causing some issues for the certification team as we have tests that deliberately generate errors and need to know how to process an error response.

Moved to 1.0 & added 'discuss' in the hope we might be able to quickly reach a consensus on this.