Credential wallet - normalizing query parameters

[sudeshrshetty]

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,

• wallet.query() can support multiple query parameters at once.
• Can make use of challenge, domain & recipient from query object.
• DID Auth can be performed using using query type DIDAuth
• VC wallet implementations can introduce their own custom query types with ease.

Challenges:

• credential query response has to be in form of verifiable presentation (since query can have domain, challenge, recipient fields ).
  I am not sure how sensible it is to generate verifiable presentation before showing query result to wallet user.

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]

@OR13 let me know your views about this.

[OR13]

@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]

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]

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

[OR13]

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]

@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]

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]

@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]

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).