Add Presentation Exchange Example

[OR13]

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]

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

[jrhender]

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]

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

[mavarley]

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]

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

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]

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

@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/"
   }
}

[msporny]

The group discussed this on the 2024-07-30 telecon:

It is possible to convert VPR to Presentation Exchange if one would like to use a single VPR but also support OID4 over VC API Exchanges. It would be useful for the specification to define how to do that to ensure that readers know that you can run OID4 over VC API in a way where the organization deploying software only needs to write a query in VPR to be able to support both VC API Exchanges and OID4. An example of code that already does that is here: https://github.com/digitalbazaar/oid4-client/blob/main/lib/oid4vp.js#L298-L380

A PR should be raised that defines the algorithm to convert a VPR to a Presentation Exchange.

[msporny]

It seems as if Presentation Exchange is going to be deprecated in OID4 v1.1 and beyond. This issue has been overtaken by events. Demonstrating an example for a request language that's being deprecated in VPR doesn't make sense. Examples using the new query language will be done via the PR to address issue #22. Marking this issue as pending close.

[jrhender]

@msporny thanks for the above update. A couple questions:

• Is Presentation Exchange being deprecated entirely as a spec or rather its usage in OID4 is being deprecated? Personally, I think that even if Presentation Exchange will no longer being used by OID4, that doesn't necessarily mean that Presentation Exchange will not be used in other contexts.
• Could you elaborate on this point "This issue has been overtaken by events" please? What does "events" refer to?

[msporny]

• Is Presentation Exchange being deprecated entirely as a spec or rather its usage in OID4 is being deprecated? Personally, I think that even if Presentation Exchange will no longer being used by OID4, that doesn't necessarily mean that Presentation Exchange will not be used in other contexts.

It is doubtful that PE will continue to be used anywhere. It was a complicated spec to start and the community has learned a number of lessons on what not to do with a query language since then. While it's true that PE might live on, there don't seem to be many in the community that are willing to put in the time and effort to take it standards track. I do expect bits and pieces of it to live on in other query languages, though.

• Could you elaborate on this point "This issue has been overtaken by events" please? What does "events" refer to?

It means that there is no standards-track effort that has has committed to progressing PE at this point in time, so putting an example in this specification for something that isn't going to reach standards status is going to mislead developers on the proper usage of the specification.