Should vc http api use PE Spec for query format?

[OR13]

Consider the following example:

Holder A wants to present credentials to Holder B

Holder A would tell Holder B "IntentToProvideDataToHolderB"

Holder B would lookup "IntentToProvideDataToHolderB", and reply with the required credential types....

if (payload.query && payload.query[0].type === 'IntentToProvideDataToHolderB') {
    return {
      query: [
        {
          type: 'QueryByExample',
          credentialQuery: {
            reason: `${domain} is requesting credentials.`,
            example: {
              '@context': ['https://www.w3.org/2018/credentials/v1'],
              type: [
                'VC1Type',
                'VC2Type',
                'VC3Type'
              ],
            },
          },
        },
      ],
      challenge: uuidv4(),
      domain: domain,
    };
  }

@mavarley @troyronda can you provide an example of this flow in PE spec for comparison?

[TallTed]

Holder A would tell holder be "IntentToProvideDataToHolderB"

I think that should be --

Holder A would tell Holder B "IntentToProvideDataToHolderB"

[jrhender]

I think this is related to https://github.com/w3c-ccg/vp-request-spec/issues/7

[mavarley]

This is also related to the /exchanges/ endpoint and protocol discovery. Current examples have VC API exchanges bound to VPR - but there is no (current) reason why it could not be a PE message.

see: https://github.com/trustbloc/wallet/blob/main/test/mock/adapter/templates/webWallet.html#L567-L643

But Trustbloc has wrapped it in the following way:

web: {
          VerifiablePresentation: {
            query: [presentationExchangeQuery],
            challenge: uuid(),

[msporny]

The group discussed this on the 2022-04-05 telecon, the only company that the group knows of having interest in implementing PE in the VC-API is SecureKey. @mavarley does SecureKey plan to do work in this area soon? If not, should we close this issue?

The group discussed if we should have a top-level primitive that is a PE in VC API -- at least two people were against the concept since we 1) don't have any implementers that have committed to PE at the top level, and 2) we have a mechanism (VPR) that can slot in arbitrary query languages, so we /can/ support PE in the future via extension points.

For this reason, suggesting that this issue is closed. Marking as 7 day close unless there are objections.

[mavarley]

Apologies for missing the call.

There are a couple implications to the above:

1. VPR is the top level protocol for VC API (exchanges, at least?)
2. Any protocol extensions would take place within a VPR context (through a VPR extension point, of which there are a few)

SecureKey would accept the above - but it does mean implementors wanting to build extensions need to implement VPR, and then their protocol within (which again, I personally see no issues with). I think this approach also allows for "safe extension", as opposed to a wild-west approach.

So how PE, DIDComm, etc.. fit within a VPR flow will be left to the organization that wants to bring that forward 'first'.

If VC API was expected to be used as the API/Resource endpoint in a OIDC4SSI flow the complications are likely more severe - as the userinfo or credential endpoint would suddenly be incompatible!

@tplooker do we need an issue for the above? Not PE specific, but rather OIDC-CP/ OIDC4SSI ?

[csuwildcat]

Block is looking to implement common methods of exchange and will be using PE within them all, so you can count us as an implementing party.

[OR13]

Trace folks have been tracking this PEx / WACI-DIDComm ticket here: https://github.com/w3c-ccg/traceability-interop/issues/17

currently no plans to implement, we are waiting for a perma url for didcomm.

[msporny]

We discussed this on the 2022-05-17 telecon. There was concern about more protocols being more difficult to demonstrate interoperability on. PRs are welcome to explore the concept.

[msporny]

The group discussed this on 2023-12-05:

@dlongley mentioned that there are OID4 implementations that use VC API Exchanges that use PE, but there isn't a need to document that since it's just an implementation of OID4. @jrhender noted that he's using PeX with VC API, but could add something, but doesn't fit necessarily since VC-API is somewhat agnostic to query language and definitions. Maybe language to state that it's agnostic might be the point of a PR. @brianorwhatever noted that this comes up in workflows, which aren't fleshed out in the spec at present. @dlongley noted that there are now 3 different protocols that have been implemented over VC API Exchanges, one of them uses VPR, if you wanted to use PE you can embed it in a VPR, OID4 uses PE, and then there is some DIDComm stuff that could use PE. Other than talking about it in that way, it's not directly related to VC API.

We discussed just closing this on the call. There were no objections to just closing (since PE is being used already in a subset of implementations). We might add language in the future to say that's explicitly OK, but implementers seem to be using PE w/ VC API today (among other exchange/query languages).