search

w3c-ccg / vc-api

A specification for an HTTP API used to issue and verify Verifiable Credentials.
https://w3c-ccg.github.io/vc-api
Other
124 stars 47 forks source link

Multi-format credential support #332

Closed PatStLouis closed 1 year ago

PatStLouis commented 1 year ago

It was discussed that the VC-API would support multiple credential formats (ex: mDL), not limited to json-ld.

Since there is currently only 1 issue-credential endpoint, how would the selection of credential format be occurring.

I can see a few options and was curious to have some opinions.

  1. Specify the credential type in the options -> options.credential.(type|filter|spec) (My favorite approach)
  2. Have a field selection in the POST data vc.(json-ld|mdl) (The kind messy approach)
  3. Have specific endpoints for each credential -> /credential/issue/<json-ld|mdl> (My least favorite approach)
  4. Have the implementation pre-defined to only support 1 type of credential.

Open to other suggestions.

I'm interested in pursuing this using the new AnonCred Spec as a PoC.

dlongley commented 1 year ago

I would expect this to be determined by the issuer instance configuration, rather than being specified via any options in the /issue endpoint. There may be reasons that a particular /issue endpoint could not issue multiple different formats for a given configuration -- so its probably best left to the issuer instance configuration. With this approach, there would be just one endpoint /issue (per instance config) -- and the caller would know which format would be issued when making calls to it.

For example:

The config for /issuers/z2136cv123v1231 causes this endpoint to issue credential format A: /issuers/z2136cv123v1231/credentials/issue

The config for /issuers/zbd32hg2873434 causes this endpoint to issue credential format B: /issuers/zbd32hg2873434/credentials/issue

dlongley commented 1 year ago

Thinking further, if it's the case that we want credentials of different formats to share the same credential status list, then we would need an option at the /issue endpoint, I'd think, to keep things simplest. I'm not sure if that's a use case worth supporting -- or if it would just be better to use different status lists in those cases.

msporny commented 1 year ago

The group discussed this on 2023-06-27:

@dlongley noted whether there should be different instances for different credential types -- for example, different status mechanisms for different formats. We might want to keep everything separate. Without enough implementation experience, challenging to say what to do here.

@PatStLouis was wondering about terminology "credential types" and "credential formats". You can add "credential types"... this one was more about format of credential itself, not necessarily being VC -- perhaps being different JSON body, mDL, AnonCredsv2, etc. If mapping AnonCredsv2 to JSON-LD credential, still JSON-LD format, but anoncreds type. Since this is VC API, wondering if supporting multiple formats is pertinent, or prior to doing that, map it to JSON-LD VC data model?

@dlongley credential types can mean RDF type as well -- we have VCs (which have base media type of application/vc+ld+json) then there are other formats (mDL, AnonCredsv2), then within VCs we have different RDF Types, and then we have other securing mechanisms as well -- VC-JWT, DI, SD-JWT, etc. So, we need to understand what's differentiated and what we need to do to support those things.

Different things we want support:

Different credential formats: W3C VCs, ISO mdoc, AnonCredsv1 Different securing formats (W3C VCs): VC-JWT, Data Integrity, SD-JWT

@PatStLouis wondered if we wanted to support all of the items above, if we include other formats, do we have to include other functionalities? @msporny noted that we are probably looking at a "Digital Credential API" over the long term. @PatStLouis noted that we might want to focus on VCs for now. @dlongley noted that we want to focus on a format and the danger we raise is that people might object to other formats being talked about in a normative way in this group. @jandrieu noted that we should stick with VCs, adding more at this point feels like feature creep, feels like expanding into other formats would complicate things. We should focus on VCs until we get the entire end to end done. @PatStLouis agreed with @dlongley and @jandrieu and noted that allowing modifications for securing formats should still be in scope.

The group decided that for v1.0 we are going to focus on W3C VCs and the securing formats that secure W3C VCs.