[Discuss] Requests for multiple credentials about digital-credentials HOT 4 CLOSED

Just adding my 2 cents here, while I believe there are some genuine use cases for these more complex scenarios, I'd just call out that it really does up the risk of failed transactions occurring, leading to user and relying party frustration.

For example what if I have all the credentials required but they are split across multiple apps/wallets, wont the platform UX be forced to basically say "no matches available" because no single wallet can service the request? This is really difficult to explain to a user or relying party what has gone wrong.

I know in certain situations asking the relying party to make multiple requests to get all the information they require may seem less efficient. But I would argue for many of the common use cases we see today its actually less disruptive to the current UX/business processes relying parties have. Many relying party experiences today have entire journeys designed where they ask users for several pieces of information during say an application process, sometimes the journey changes along the way depending on what you submit (another potential reason to not ask for everything in one request). A credential request API focused on singular requests that can integrate along side where maybe a file picker would have been used in the past to request a photographic/file based version of a "credential" feels like a much simpler place to start and build from.

Lastly in the cases you describe above if the browser API were focused on single credential presentation (at least initially) I could see that each usecase could still be accommodated just through a slightly different modelling, for example

Submitting a digital driver's license and a liveness credential (the person that is interacting is the person that is on the card).

In my head I'd model it as the only credential here is the DL, the liveness is just an assertion from the wallet provider which can be included in the presentation instead of it being modelled as a seperate credential.

Submitting a passport and an assertion that the signing key for the presentation is protected by a Hardware Security Module (HSM)

Same as the above, the assertion about the signing key could be put in the VP.

Submitting an employment authorization document and an I-9 (Employment Eligibility Verification) form.

Is the intent here that the I-9 form being submitted by the user is a credential?

Provide a set of all course completion and continuing education credits for a particular calendar year.

Or perhaps alternatively a singular transcript credential with all the courses completed?

Suffice to say I'm personally wary of what I see as the less common but more complex use cases making the overall API more difficult to use during the first wave of adoption.

from digital-credentials.

I don't believe there is anything in the current proposal that would prevent a wallet from sending multiple presentations in the response, as long as they are both being generated from the same wallet (see #26).

from digital-credentials.

I don't believe there is anything in the current proposal that would prevent a wallet from sending multiple presentations in the response, as long as they are both being generated from the same wallet (see #26).

That's great to hear @timcappalli!

To be clear, the expectation is that all of the following would be possible:

• A Verifier (RP) can send a presentation request that could only be filled by providing multiple digital credentials (e.g., employment authorization document + I-9 form).
• A Holder (Wallet) code (WASM blob) that runs in the browser could determine that it has all of the documents requested.
• A Holder (Wallet) can provide a single presentation containing multiple digital credentials, or multiple presentations in a single response to the Verifier (RP).
• An Issuer can send multiple digital credentials to a Holder (Wallet) during an issuance process.

If all of the above is possible, we're golden. I was under the impression that browser implementers wanted to "keep things simple" by only ever requesting and responding with a single digital credential (such as an mDL).

from digital-credentials.

@msporny OS platform APIs that interface with the wallet may have that limitation, but I don't see how the web platform API in the current proposals (e.g. just passing a request string, and expecting a response string) would prevent it.

from digital-credentials.