Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Would there be a standard list for credential_formats_supported? #55

Open
Sakurann opened this issue Apr 15, 2021 · 3 comments
Open

Would there be a standard list for credential_formats_supported? #55

Sakurann opened this issue Apr 15, 2021 · 3 comments

Comments

@Sakurann
Copy link

Would be confusing if w3cvp-jwt and vp-jwt and vp_jwt would be used for the same thing..?

@AdamJLemmon
Copy link
Contributor

Yes we definitely need to align, DIF PE included (jwt_vc ), on consistent naming for these things.
Not sure the right place to have that discussion / note the decisions..

@tplooker
Copy link
Member

Yes it would be good to have these defined in a registry and managed in IANA

@alenhorvat
Copy link

What is your view on:

  • different countries have different schemas (for different credentials)
  • different countries would probably issue the same VC type (eID, diploma, driver's license, ...) in different format(s)
  • should the user get a VC in different formats or should verifiers have the capability to validate all the different formats?

Today we mostly have jwt, ldp; however many existing service are using XML (or other formats)
W3C VC states that the specs are not limited to JSON/JSON-LD.

In the future, we may have other non-w3c VCs/VPs.
Would it make sense to define the format as an object with properties like:

  • format (jwt, ldp, XML, ...)
  • type or cty (vc, vp)
  • version? (should vc/vp version be implicit or explicit?)
    or a combination of
  • format
  • schema_uri (link to the json or json-ld schema, for example)

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants