Support Multi-Stage Applications
decentralgabe opened this issue · 9 comments
A common KYC process:
- Submit your drivers license
- OK, validated, now submit a selfie
- 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
This seems like there's some correlation with this issue and decentralized-identity/presentation-exchange#364. Mitch from Flindev figured out the relationship @scrummitch
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.
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.
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
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.
If anything this raises the importance of including an implementers guide or at least more examples that can demonstrate multi-step interactions.
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
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.