2C/ Verifiable Credential V2 - Charter Scope etc.

From IIW

Verifiable Credentials V2


Session Convener: Brent Z and Kristina Y

Notes-taker(s): Steve Venema

Tags / links to resources / technology discussed, related to this session:


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


~35 attendees


In Scope:

  • Fix issues with previous versions of the VC data model
  • What’s the data model for requesting information
  • Registries for the data model
  • Algorithms for the expression of proofs (missing from older specs)
  • Refining multilingual support in the data model
  • Explicitly not a req’t that the new specs be fully compatible with past versions

Out of Scope:

  • We don’t care what ledger to use for VC ecosystem
  • The specification of new cryptographic primitives
  • The normative spec of APIs or protocols

…still a data model specification


The objects are being defined The flow is not being defined (though it it may be shown as examples of *a* way to do something)


Normative Deliverables

  • VC Data model (VCDM) 2.0
    • Next version of the data model.
    • Open questions about data format (just JSON? CBOR? …?)
  • Securing Verifiable Credentials (SVC) 1.0
    • Normatively fill the proof section missing from older specs
    • Cryptosuites for VC-JSON Web Token (JWT): IANA JOSE Algorms Registry
    • Cryptosuites for Data Integrity: JSON Web Signature 2020, EdDSA, NIST ECDSA, Koblitz ECDSA


Conditional Normative Deliverables Depends on progress in the W3C Credentials Community Group, the IETF, and the DIF, this WG may also produce W3C recommendations based on the following documents. This is an example set, may do other things (or not)

  • PGP Cryptosuite
  • BBS+ Cryptosuite
  • VC protection using JWPs
  • Koblitz ECDSA Recovery Cryptosuite


Q: List of issues from existing specs A: We have a list of errata. Please file issues on the spec–you don’t need to be a member. Existing spec issues automatically get promoted

Q: How long is this lifespan before we have 3.0? A: V2 will come out in ~2 years. So keep using V1

Q: What about chained credentials (AC/DC topic) A: Nothing in our effort precludes this, but we need participation from people in that space to make sure the new specs support it.

Note: the VC-v2 WG hasn’t started yet, so you haven’t missed anything (yet)

Kristina: maybe this is happening a bit early, but the forcing function is standardization of the signatures

Q: Does the WG have a philosophy on quantum attacks? A: We aren’t crypto experts, but if there is a signature approach that is quantum resistant, then we can choose this.

Req’t from W3C is if we want to refer to an external spec, then it needs to be something that comes from a standards org that issues normative specs


Registries

The WG may create a set of registries including registry definitions and registry tables to support extension points in the above normative deliverables. Ex: VC properties that MUST be included in a VC, must have at least one standardized entry. Motivation: we don’t know what will be coming after the WG is done–allows the spec to evolve in a normative way. MUST have at least one item in the registry–allows for testability and avoid kicking cans down the road


Q: Could this WG support the property graph approach of the AC/DC work? A: Yes, but we need participation in order to develop consensus


Other Deliverables

Things we may do some or none of these:

  • Test suites for all normative deliverables
  • Presentation Request Data Model
  • Storage and Sharing of VCs
  • Privacy Guidance for Verifiable Credentials
  • Extensions for binding multilingual resources for localized user interfaces
  • A Developer Guide consisting of one or more notes related to general implementation guidance and best practices
    • One or moreHTTP protocols definitions for VC Exchange (such as VC-API)
    • Guidance on VC Exchange offer OIDC
    • VC exchange over Grant Negotiation and Authorization Protocol (GNAP)
    • Other protocols as time and attention and resources permit
  • Guidance to enhance VC interoperability
    • VC extension vocabularies (e.g., ISO 18013-5 mDL)
    • Implementation Guides
    • Test Suites


Q: What about revocation? A: Brent: I would put this under the “Storage and “Sharing of VCs’” topic

Q: Most use cases require revocation

Q: How about VC lifecycle A: We aren’t doing APIs, but it should be possible to use our data models and give guidance on this.

Brent: We need to keep the charter concise; the audience is the AC’s who review these They want something that has a limited lifetime. 2 years is typically the limit. You can ask for extensions, but you need to show great progress before this.

Github repo: vc-data-model

Q: How to approach complexity management – like encoding variants. A: Brent (personal opinion): I think it should be very limited. But as WG chair I want to encourage other proposals. A: Kristina: ideally we’d like to have just one encoding

Q: registry for the schemas A: wouldn’t expect that Comments: <couldn’t hear clearly> Comment: Don’t mistake encoding for schema

Q: How can we participate A: If you are a member of W3C have your AC representative register. If you aren’t in a position to join W3c, reach out to Kristina and Brent as there are options to still participate A: WG hasn’t started yet (taking a bit of a break). Expect a weekly cadence.

Retrieved from "https://iiw.identitycommons.net/index.php?title=2C/_Verifiable_Credential_V2_-_Charter_Scope_etc.&oldid=24193"