CR Request for "Verifiable Credentials Data Model v2.0" - vc-data-model-2.0/

[iherman]

Document title, URLs, estimated publication date

• Verifiable Credentials Data Model v2.0 (VC-DATA-MODEL-2.0)
  • https://www.w3.org/TR/2024/CR-vc-data-model-2.0-20240123/
  • 23 January 2024
  • Editors' draft: https://w3c.github.io/vc-data-model/

Abstract

• https://w3c.github.io/vc-data-model/CR/2024-01-23/#abstract

Status

• https://w3c.github.io/vc-data-model/CR/2024-01-23/#sotd

Link to group's decision to request transition

• https://www.w3.org/2017/vc/WG/Meetings/Minutes/2024-01-10-vcwg#resolution2

(Note: the resolution says publication date Jan 30, but it has then decided to move it ahead, if possible)

Changes

• https://w3c.github.io/vc-data-model/CR/2024-01-23/#revision-history

Requirements satisfied

Yes.

Dependencies met (or not)

All normative dependencies for VC Data Model v2.0 are either RECs or IETF RFCs, except for:

• VC-DATA-INTEGRITY, which entered CR in November 2023.
• VC-JOSE-COSE, which is a WD and is expected to enter CR in Q1 2024.

Wide Review

Issues processed:

• https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aclosed+created%3A%3E2022-06-13

PRs processed:

• https://github.com/w3c/vc-data-model/pulls?q=is%3Aissue+is%3Aclosed+created%3A%3E2022-06-13

Horizontal reviews (for VC-DATA-MODEL-2.0):

• TAG: Verifiable Credentials Data Model v2.0 w3ctag/design-reviews#860 (request timeout)
• PING: Verifiable Credentials Data Model v2.0 2022-06-15 w3cping/privacy-request#121 (completed)
• Security: Verifiable Credentials Data Model v2.0 2022-06-15 security-request#58 (request timeout)
• a11y: Verifiable Credentials Data Model v2.0 2021-06-15 a11y-request#65 (completed)
• i18n: Verifiable Credentials Data Model v2.0 2023-06-15 > 2023-07-21? i18n-request#212 (completed)

Liaisons:

• There is participants' overlap with the following liaison groups:
  • RDF Canonicalization and Hashing Working Group
  • Decentralized Identifier Working Group
  • Credentials Community Group
  • Internet Engineering Task Force
  • Internet Engineering Task Force Crypto Forum Research Group
  • Hyperledger Aries
  • Decentralized Identity Foundation Interoperability Working Group
  • IMS Global
  • ISO/IEC JTC 1/SC 17/WG 10
  • ISO/IEC JTC 1/SC 17/WG 4
• Web of Things Working Group
  • Joint meeting at W3C TPAC 2023
• APA Working Group
  • See horizontal reviews
• National Institute of Standards and Technology, U.S. Department of Commerce
  • DHS actively engaged w/ NIST over VCWG + Justin Richer NIST SP 800-63-C work
• The American Civil Liberties Union
  • Presentations given to ACLU and CDT over the years via PING and other venues
  • ACLU, EFF, CDT, and EPIC paper speaking positively about VCs:
    https://www.eff.org/document/10-16-2023-aclu-eff-epic-comments-re-tsa-nprm-mdls
• European Telecommunications Standards Institute
  • EU Digital Wallet cites/uses VCWG output + ARF + EBSI

Formal Objections

None.

Implementation

https://w3c.github.io/vc-data-model-2.0-test-suite/

Patent disclosures

None, see

• https://www.w3.org/groups/wg/vc/ipr/

---

cc: @msporny @TallTed @selfissued @decentralgabe

[ylafon]

Note that the TAG didn't timeout, there was a comment last December w3ctag/design-reviews#860 (comment) and it is on the agenda of the TAG f2f next week.

[iherman]

Note that the TAG didn't timeout, there was a comment last December w3ctag/design-reviews#860 (comment) and it is on the agenda of the TAG f2f next week.

Just for the record: there was a (long) answer to that comment in w3ctag/design-reviews#860 (comment) on which the WG received no reactions.

[plehegar]

What's the status of IANA registration for aplication/vc+jd+json and application/vp+jd+json ? I could not find anything about those in the registry or the provisional registry. A search on the list media-types did not return a request for review.

[plehegar]

https://w3c.github.io/vc-data-model-2.0-test-suite/ uses the Group Note template. Please change it to editor's draft or something else. /TR templates should only be used on documents actually published in /TR.

[iherman]

At the moment it is not possible, afaik, to register a vc+jd+json media type (ie, with two '+' signs); there is an ongoing work at IETF to allow that. We are waiting for that process to conclude.

@msporny is an active editor of that IETF effort, and I let him go into the details.

If the issue is not solved by the time this document is ready to go ahead, we will have to re-issue a snapshot with alternative media types that use only '+' signs...

[plehegar]

At the moment it is not possible, afaik, to register a vc+jd+json media type (ie, with two '+' signs); there is an ongoing work at IETF to allow that. We are waiting for that process to conclude.

Do you have a pointer to the request or the thread?

And note that application/vc nor application/vp are registered, despite being used by VC 1.

[plehegar]

To make sure: media type registration won't be a blocker to move to CR but we should clean the status before moving to PR.

[iherman]

At the moment it is not possible, afaik, to register a vc+jd+json media type (ie, with two '+' signs); there is an ongoing work at IETF to allow that. We are waiting for that process to conclude.

Do you have a pointer to the request or the thread?

@msporny ?

And note that application/vc nor application/vp are registered, despite being used by VC 1.

Oops... :-)

[iherman]

https://w3c.github.io/vc-data-model-2.0-test-suite/ uses the Group Note template. Please change it to editor's draft or something else. /TR templates should only be used on documents actually published in /TR.

See the w3c/vc-data-model-2.0-test-suite#63 PR.

[brentzundel]

Note that the TAG didn't timeout, there was a comment last December w3ctag/design-reviews#860 (comment) and it is on the agenda of the TAG f2f next week.

The TAG was explicitly offered a reasonable opportunity to review in June 2023. We were grateful to receive feedback and did respond to that feedback.

We of course look forward to any additional review from the TAG or anyone else as we move forward, but hope that this transition request won't be delayed while waiting for that further review.

[TallTed]

At the moment it is not possible, afaik, to register a vc+jd+json media type (ie, with two '+' signs); there is an ongoing work at IETF to allow that. We are waiting for that process to conclude.

IETF Media Type registrations do not disallow media types with multiple + (plus sign); the concern has been that "correct" interpretation of such media types has not been defined.

A draft RFC addressing this topic has been in active process for many months, with current hopes that it will go to "last call" at the next IETF meeting.

[msporny]

@plehegar wrote:

note that application/vc nor application/vp are registered, despite being used by VC 1.

Neither application/vc or application/vp are used in VC 1.0 and 1.1, nor was there a desire to register those particular media types.

What you might be doing, @plehegar, is reading the IANA Considerations section in VC 1.1 too quickly :) -- the section registers vc and vp in the "JSON Web Token Claims Registry"... it doesn't register any media types.

IIRC, the topic of registering a media type did come up during VC 1.0, but the WG decided to delay registration during VC 1.0, and delayed yet again during VC 1.1.

That ended up being a good call, because it took months in the VC 2.0 WG to debate the appropriate media type and the ramifications for VC 2.0, and as a result we do plan to register the media types listed in the current VC 2.0 spec, which we have used as a focal use case in the IETF MEDIAMAN WG, which is standardizing media types with multiple suffixes (as @TallTed mentioned above). We can register the VC 2.0 media types as soon as the multiple suffixes draft completes IETF Last Call (and we can signal the intent in the VC 2.0 spec, as we did in the DID Core 1.0 specification, as a way of getting through PR).

I am the reluctant lead Editor for the media types with multiple suffixes specification at IETF, which was created to provide guidance on what having multiple plus signs in a media type means. We triggered this question when we tried to register the DID Core media type. The suffixes draft document is standards track at IETF, has had multiple iterations at IETF meetings, and is expected to go into IETF LC during the next meeting. There remains one issue, which I plan to write text to resolve in the next couple of weeks.

All that to say, the IETF MEDIAMAN WG knows about our plans to register the VC 2.0 media types and acknowledged that they don't see an issue with us proceeding once the IETF is done with their document (unfortunately, I couldn't find that statement in the minutes, but both @brentzundel and I attended that meeting). Even if the timelines don't line up for the PR, we can do what we did for DID Core and progress through to REC with that strategy in place.

I hope that helps clarify the media type registration concerns that have been raised.

[plehegar]

@plehegar wrote:

note that application/vc nor application/vp are registered, despite being used by VC 1.

Neither application/vc or application/vp are used in VC 1.0 and 1.1, nor was there a desire to register those particular media types.

What you might be doing, @plehegar, is reading the IANA Considerations section in VC 1.1 too quickly :) -- the section registers vc and vp in the "JSON Web Token Claims Registry"... it doesn't register any media types.

Indeed, I was.

IIRC, the topic of registering a media type did come up during VC 1.0, but the WG decided to delay registration during VC 1.0, and delayed yet again during VC 1.1.

That ended up being a good call, because it took months in the VC 2.0 WG to debate the appropriate media type and the ramifications for VC 2.0, and as a result we do plan to register the media types listed in the current VC 2.0 spec, which we have used as a focal use case in the IETF MEDIAMAN WG, which is standardizing media types with multiple suffixes (as @TallTed mentioned above). We can register the VC 2.0 media types as soon as the multiple suffixes draft completes IETF Last Call (and we can signal the intent in the VC 2.0 spec, as we did in the DID Core 1.0 specification, as a way of getting through PR).

I am the reluctant lead Editor for the media types with multiple suffixes specification at IETF, which was created to provide guidance on what having multiple plus signs in a media type means. We triggered this question when we tried to register the DID Core media type. The suffixes draft document is standards track at IETF, has had multiple iterations at IETF meetings, and is expected to go into IETF LC during the next meeting. There remains one issue, which I plan to write text to resolve in the next couple of weeks.

All that to say, the IETF MEDIAMAN WG knows about our plans to register the VC 2.0 media types and acknowledged that they don't see an issue with us proceeding once the IETF is done with their document (unfortunately, I couldn't find that statement in the minutes, but both @brentzundel and I attended that meeting). Even if the timelines don't line up for the PR, we can do what we did for DID Core and progress through to REC with that strategy in place.

I hope that helps clarify the media type registration concerns that have been raised.

It does, thank you. Glad you're on top of it.

[plehegar]

At this point, we're waiting on @ylafon to confirm nothing blocking comes from the TAG at their f2f meeting this week.

[plehegar]

Unfortunately, the TAG could not discuss this during their face-to-face meeting. Having looked at the original comment from the TAG and the response from @msporny , I don't see anything blocking for the transition. The TAG may come back with additional comments later.

Approved.

[msporny]

I have prepped the CR-ready document and placed it here: https://w3c.github.io/vc-data-model/CR/2024-02-01/

[iherman]

Thanks PlH. I presume the ball is in my court now, but I guess you should change the right labels...

[iherman]

Published on 2024-02-01. Closing.