decentralized-identity / credential-manifest

Format that normalizes the definition of requirements for the issuance of a credential
https://identity.foundation/credential-manifest/
Apache License 2.0
30 stars 22 forks source link

Support Multi-Stage Applications #133

Open decentralgabe opened 2 years ago

decentralgabe commented 2 years ago

A common KYC process:

  1. Submit your drivers license
  2. OK, validated, now submit a selfie
  3. OK, validate, here's your credential

With CM today we cannot represent this type of interaction. Notably (2) is depending on the processing and validation of (1). More specifically the issuer needs proof of completion of one step to proceed with a second.

One way to solve for this would be to have a concept of "multi-part manifest" which allows you to chain together sub-manifests and accept sub-applications based on the original manifest and its submission. Another way to address this is potentially more simple: alter the "CredentialResponse" to return either fulfillment, denial, another manifest. It's also possible that we alter "Fulfillment" to include a credential AND another manifest.

cc: @csuwildcat

andorsk commented 2 years ago

This seems like there's some correlation with this issue and https://github.com/decentralized-identity/presentation-exchange/issues/364. Mitch from Flindev figured out the relationship @scrummitch

andorsk commented 2 years ago

It was suggested from @nklomp that Present Proof v2 from Aries might be the answer to this, but I'm not sure this is the optimal solution ( though I admit I'm still working on a better way to do it ) and what he's proposed is so far the closest to a solution I've seen.

My gut is that there's an advantage toward baking in some interaction guidance into the presentation/CM specifications themselves as I think @decentralgabe is suggesting.

decentralgabe commented 2 years ago

Yeah I mainly want to have a discussion on whether we have PE and CM as protocols or just data models. This suggestion has a risk of making that distinction a bit more gray.

nklomp commented 2 years ago

I guess the benefit of current spec is that it can be used in all kinds of transport mechanisms (OID4VP, WACI-DIDComm, VC-API) etc. If we want to retain that the only path forward I see is to have something that can be interpreted on both sides from a single exchange.

So then having a graph like decision structure in PE makes sense.

The other solution I can see is to go down an exchange protocol path, like Aries Present Proof. That then has to be a seperate spec and almost certainly cannot support all other protocols, simply because they typically cannot handle multiple interactions

djvs commented 2 years ago

Speaking from current implementation needs @ Bloom, we're definitely seeing intermediate out-of-band steps need to take place in between, so any approach should definitely support asynchronicity. That's likely a hint that multiple requests should be handled as entirely separate, or wrapped in a broader concept.

decentralgabe commented 2 years ago

If anything this raises the importance of including an implementers guide or at least more examples that can demonstrate multi-step interactions.

kimdhamilton commented 1 year ago

Per discussion on Nov 10, all agree with consensus of this thread -- focus of CM and PE should on data model (not protocol).

To @decentralgabe's point, we can approach this as add to an implementation guide or examples.

If the need emerges for additional data models resulting in substantive changes to the spec, we can revisit that.

Creating a label "editorial" to classify this as "would be nice", but not blocking to the spec

andorsk commented 1 year ago

Tom Jones on the Nov 11 C&C call brought up an excellent point in the chat during the PE call that I wanted to note: that if there was a "continuation" like exchange, where you could lead people down a chain of claims, and that there could be some legal implications to it. I was a really interesting thought so wanted to make sure I had it caught for reference later.

csuwildcat commented 1 year ago

This may be a fantastic candidate for creating a multi-step credential issuance protocol using the DWN Protocols capabilities, which allow for turn style activities like this.

On Thu, Nov 10, 2022, 12:49 PM Andor Kesselman @.***> wrote:

Someone ( keeping anon for privacy, check the recording for the name ), on the Nov 11 C&C call brought up an excellent point in the chat during the PE call that I wanted to note: that if there was a "continuation" like exchange, where you could lead people down a chain of claims, and that there could be some legal implications to it. I was a really interesting thought so wanted to make sure I had it caught for reference later.

— Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/credential-manifest/issues/133#issuecomment-1310751403, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABAFSTXONHMXL3E754CICLWHU7SXANCNFSM6AAAAAARXRNRPA . You are receiving this because you were mentioned.Message ID: @.*** com>