w3c-ccg / vp-request-spec

Specification for a query language to request Verifiable Presentations from wallets etc.
https://w3c-ccg.github.io/vp-request-spec/
Other
10 stars 3 forks source link

Add Presentation Exchange Example #7

Open OR13 opened 4 years ago

OR13 commented 4 years ago

https://github.com/decentralized-identity/presentation-exchange

https://identity.foundation/presentation-exchange/#chapi

essentially, the request query is a special type, and the response is an extended VP...

Examples and cross linking would be helpful.

dmitrizagidulin commented 4 years ago

@OR13 oh, very cool, thanks! Will take a look.

jrhender commented 2 years ago

Would a query like this make sense to add to the spec?

{
   "type":"PresentationDefinition",
   "credentialQuery":[
      {
         "presentationDefinition":{
            "id":"32f54163-7166-48f1-93d8-ff217bdb0653",
            "input_descriptors":[
               {
                  "id":"wa_driver_license",
                  "name":"Washington State Business License",
                  "purpose":"We can only allow licensed Washington State business representatives into the WA Business Conference"
               }
            ]
         }
      }
   ]
}
OR13 commented 2 years ago

@mavarley this would be a great one for you to answer.

mavarley commented 2 years ago

Hi @jrhender I believe the TrustBloc project has a sample of using PE within the VPR (which is the protocol currently spec'd in both CHAPI and some of the VC API examples) and I will attach that when I can locate it :)

Part of the /exchange/ discovery message was to allow a VC API to support a PE message exchange, and not require VPR at all...

jrhender commented 2 years ago

@mavarley You linked to an example from the TrustBloc project here: https://github.com/w3c-ccg/vc-api/issues/174#issuecomment-1088721264 (here is the link for reference: https://github.com/trustbloc/wallet/blob/main/test/mock/adapter/templates/webWallet.html#L567-L643 ) I'm gathering this is the sample you were referring to?

If so, it seem what TrustBloc has done is a VPR credential query that looks like

{
   "type":"PresentationExchange",
   "credentialQuery": {
       "id":"32f54163-7166-48f1-93d8-ff217bdb0653",
       "input_descriptors":[]
   }
}

Comparing that to what I suggested above: (which is what EnergyWeb has implemented, for example https://github.com/energywebfoundation/ssi/blob/7a0001cefbe64c34d64d7684e04b6b0f52c2b2a3/apps/vc-api/test/vc-api/exchanges/resident-card/resident-card-presentation.exchange.ts#L42)

{
   "type":"PresentationDefinition",
   "credentialQuery":[
      {
         "presentationDefinition":{
            "id":"32f54163-7166-48f1-93d8-ff217bdb0653",
            "input_descriptors":[ ]
         }
      }
   ]
}

@mavarley Is this an accurate comparison in your view?

Regarding

Part of the /exchange/ discovery message was to allow a VC API to support a PE message exchange, and not require VPR at all

I think it is still valuable to continue the discussion of how to include a PresentationDefinition as a credential query in VPR, even if there is some discussion about VPR at the top-level in VC API. I've found the "Interaction Types" feature of VPR to be useful with VC-API exchanges, so to me it makes sense to keep working on the "PEx in VPR" case for now.

mavarley commented 2 years ago

hi @jrhender ; is the intention of making the PresentationDefinition a sub object to allow for multiple Queries? And keep the PresentationDefinition in its own 'clean' separate object?

I am inviting @rolsonquadras and @sudeshrshetty to participate, as they did the TrustBloc implementation.

sudeshrshetty commented 2 years ago

@jrhender @mavarley TrustBloc supports both variant of credential queries, single object or array.

{
   "type":"PresentationExchange",
   "credentialQuery": {
       "id":"32f54163-7166-48f1-93d8-ff217bdb0653",
       "input_descriptors":[]
   }
}

and

{
   "type":"PresentationExchange",
   "credentialQuery": [{
       "id":"32f54163-7166-48f1-93d8-ff217bdb0653",
       "input_descriptors":[]
   },
   {
       "id":"42f54177-7967-99f1-93d8-gg666bdb8765",
       "input_descriptors":[]
   }

   ]
}

we followed similar pattern in universal wallet Query interface & in this example

The differences I see with your sample are type and one extra level presentationDefinition under credential query. Can I know the motivation behind having that extra level credentialQuery[*]. presentationDefinition?

jrhender commented 2 years ago

@sudeshrshetty Thanks for the clarification on single object vs array. I know my example had array, but I actually think that single object makes more sense. I'm curious if you had a use case where the array (with multiple presentation definitions) was useful?

The differences I see with your sample are type and one extra level presentationDefinition under credential query.

I agree that these are the differences.

Regarding type, I think that PresentationDefinition is a bit more accurate. This could be useful if, for instance, maybe the Presentation Exchange spec evolves in the years to come and adds another possible "query" type, in which case the accuracy could be handy. I don't feel that strongly about this though. Do you think PresentationExchange is better?

Regarding credentialQuery[*]. presentationDefinition, I think that having the actual PresentationDefinition as a value to a key makes it a more flexible in the event that we want add additional keys. Actually, now that we're on the topic, it occurred to me that maybe we should add a spec version somewhere. I'm not sure this is necessary, but it could be useful as the spec evolves. For example:

{
   "type":"PresentationDefinition",
   "credentialQuery":{
      "presentationDefinition":{
         "id":"32f54163-7166-48f1-93d8-ff217bdb0653",
         "input_descriptors":[]
      },
      "specificationURI":"https://identity.foundation/presentation-exchange/spec/v1.0.0/"
   }
}