what to use for issuance?

[brentzundel]

• presentation exchange?
• Aries RFCs?
• credential manifest?

this issue is a place to have the conversation. please feel free to propose additional notions/concerns/etc.

[agropper]

How is this different from what's being done in VC-API https://w3c-ccg.github.io/vc-api/ ?

[brianorwhatever]

@agropper this flow will likely be completed over didcomm while vc-api remains out of the box http oriented

[agropper]

@brianorwhatever

1 - Although V-API may be currently HTTP oriented, their security protocol is having to deal with HTTP-agnositc authorization models like GNAP and removing HTTP from the spec title is a step in that direction. It might make sense for the SSI community to try to avoid fragmentation of how the VC and DID data models are marketed.

2 - If WACI presumes or stipulates DIDComm as a foundation privacy issues will arise to the extent that DIDComm requires the controller to identify themselves to the Issuer using a DID. In general, the Issuer more power than the Subject but the Subject has the option to approach an Issuer anonymously at first, using did:key and onion routing, for example. The Issuer then has the option (disclosed publicly via .well-known privacy policies) to restrict VC issue to parties they can authenticate somehow.

In general, the Issuer is processing a "request" on an open public endpoint. If the open endpoint requires authentication to proceed with a request, then the next phase is no longer open and public. I hope for clarity on how WACI / DIDComm would handle the request phase of a VC issue transaction? Does the Issuer use DIDComm to authenticate the requesting party?

FWIW, GNAP handles this situation by explicitly standardizing the request for as well as the secure flows related to authorized issuance. DIDComm may be compatible with GANP flows when messaging is called for.

[OR13]

Lets move to discussion, we have already started to support some of this in the current spec.