w3c-ccg / universal-wallet-interop-spec

A data model and abstract interfaces for digital wallets
http://w3id.org/wallet
Other
56 stars 13 forks source link

Credential wallet - normalizing query parameters #85

Open sudeshrshetty opened 3 years ago

sudeshrshetty commented 3 years ago

For VC wallet query interface, I propose to make query types inline with vp-request-spec api so that it can support wide range of query types in future and also it will make wallet credential queries standardized.

Other benefits,

Challenges:

To be discussed: Since presentation exchange response (presentation submission) is in form of Verifiable Presentations. Mixing it with other credential query types like QueryByExample, QueryByFrame may produce multiple presentations as query results. Either we have to normalize results to single presentation or return multiple presentations as query result.

sudeshrshetty commented 3 years ago

@OR13 let me know your views about this.

OR13 commented 3 years ago

@sudeshrshetty I agree with this approach, and I am actually working on a version of it already, as I try to sort out vp exchange api's at the wallet layer (before network).

ping @msporny @dmitrizagidulin (relates to chapi / vp- request spec).

msporny commented 3 years ago

Acknowledging that I saw this... I don't quite know what "I propose to make query types inline with vp-request-spec api" means... vp-request-spec already supports that, and if universal-wallet-interop supports vp-request-spec and CHAPI, then it all just works? Or am I missing something -- is universal-wallet-interop-spec coming up with it's own vp exchange API?

OR13 commented 3 years ago

@msporny its not, its exposing vp-request spec as a set of wallet apis... that can be interacted with over http or chapi.

OR13 commented 3 years ago

we had/have a wallet query operation which was/is more generic, but has not really been used for anything... this proposal is to make it directly compatible with the vp-request spec, so that vp request spec is the query interface for VC/VP... but obviously vp-request spec does not support all the data models of the universal wallet, hence the need to harmonize wallet query interfaces.

sudeshrshetty commented 3 years ago

@msporny I am not sure if chapi/vp-request-spec supports returning multiple presentation as query result. (query results may contain multiple presentations if PresentationExchange is mixed with other query types)

msporny commented 3 years ago

we had/have a wallet query operation which was/is more generic, but has not really been used for anything... this proposal is to make it directly compatible with the vp-request spec, so that vp request spec is the query interface for VC/VP... but obviously vp-request spec does not support all the data models of the universal wallet, hence the need to harmonize wallet query interfaces.

Acknowledged. I'm supportive of attempting to simplify and harmonize.

msporny commented 3 years ago

@msporny I am not sure if chapi/vp-request-spec supports returning multiple presentation as query result.

It doesn't, on purpose, in an attempt to keep the development environment simple and straight forward.

(query results may contain multiple presentations if PresentationExchange is mixed with other query types)

This is the sort of complexity that should concern all of us. Think about how difficult that programming model is going to be for a Web developer that has a ton of other things to worry about wrt. their website. Let's say you get 3 completely different presentations returned to you, and they all have different information in them... which one do you use? One of them, a combination of them?

Enabling the data model to support this is easy... but it creates an explosion in complexity. That's the concern.

sudeshrshetty commented 3 years ago

I agree with that.

@OR13 In that case, I guess we can try the option of normalizing response presentations to single presentation (before signing) or we should validate request queries against producing multiple presentations as response (PresentationExchange queries shouldn't be mixed).