Be clear that defining some fields means defining the ceremonies they point to

[jyasskin]

@msporny mentioned in w3c/vc-data-model#866 (comment) that the refreshService registry is likely to include a document based on https://digitalbazaar.github.io/vc-refresh-2021/. This document defines a ceremony, in the sense of Ceremony Design and Analysis, for helping a human refresh their credential. I see in #24 that the inclusion of protocols is controversial, but a data model isn't rigorously defined if it includes URIs that point to undefined endpoints. The charter shouldn't commit the group to underspecifying your data model.

This doesn't mean that this group needs to define all the endpoints: if there's an existing specification you can point to, that's fine.

[msporny]

The charter shouldn't commit the group to underspecifying your data model.

The vast majority of the VCWG is aligned with your view, @jyasskin.

There are a few people in the VCWG that are attempting to put the WGs ability to discuss protocol implications and publish notes about protocol out of scope: #43 #43 (comment)

I will note that some of these same people were involved in actively limiting the scope of the DID WG such that we ended up with the overly narrow charter that we did.

I suggest that you take a look at this PR to get an idea of where the majority of the WG wants to go: #66

[mprorock]

+1 @msporny

[jyasskin]

I'm uncomfortable with the way that #66 commits to avoiding all REC-track protocols: if a field in the data model holds a URI, and the processor is supposed to fetch or navigate to that URI and do something with the result, that's a (small) protocol or ceremony that needs to be REC-track in order for data model to have actually defined the field.

On the other hand, if VC documents are just chunks of data interchanged within a larger system (perhaps the VC API system), and the URIs inside them are used as pure IDs instead of fetch/navigation targets, then it'd be fine to keep mention of that larger system non-normative.

[msporny]

the URIs inside them are used as pure IDs instead of fetch/navigation targets

The URIs are fetch/navigation targets, not purely IDs.

If APIs were to be put in scope, the WG would still need to focus on the cryptographic bits /first/ before moving on to protocol. Given that we have repeatedly been slapped on the hand for broad charters by AC members, we are trying to be conservative with our scope -- work on the cryptography bits in a focused manner, publish some non-normative protocol NOTEs, and then recharter to work on protocols (while running that work in parallel in the W3C Credentials Community Group so it's already spec'd, test suite'd, and ready for a quick iteration in VC 3.0 WG).

[selfissued]

There are a few people in the VCWG that are attempting to put the WGs ability to discuss protocol implications and publish notes about protocol out of scope

For the record, I've publicly supported us being able to discuss protocol implications during the working group calls. I gave the example that the aud (audience) claim was included in JWTs because we knew that protocols, such as OpenID Connect, needed it. That's different but discussing protocol implications is different than the working group normatively defining protocols and APIs for using VCs.

There is working group consensus for us to not normatively define protocols and APIs - as reflected in PR #70, which was merged during yesterday's working group call.

[jyasskin]

@selfissued I think that implies a commitment to move fields like refreshService back to incubation, since the URIs they contain are undefined without a specification of the protocols or ceremonies they refer to. That would be fine with me, but I want to be sure the WG is conscious of the tradeoffs it's making.

[msporny]

@jyasskin wrote:

@selfissued I think that implies a commitment to move fields like refreshService back to incubation, since the URIs they contain are undefined without a specification of the protocols or ceremonies they refer to. That would be fine with me, but I want to be sure the WG is conscious of the tradeoffs it's making.

That's definitely not what a significant portion of the WG expects is being done here. Again, this is a delicate balance. A number of members of the current VC WG (who will be participating in the next WG) do intend to publish notes on protocols, so there will be documents to refer to (non-normatively, but still, the documents will exist in W3C VCWG space). There is agreement to not publish normative protocols in this iteration. The current PRs indicate that the WG /will/ publish NOTES on protocols, that can be referenced by the core specs if needed. Those references from the core specs, for example for refreshService, will be able to at least point to non-normative documents published by the WG on protocols that have influenced the normative data model definitions.

Again, the goal here is to focus on normative data-model related things in the WG with call outs to non-normative WG produced content on protocols (to ensure that the data models aren't just a hand wave at what's going on at the protocol layer, which is receiving active incubation, implementation, deployment, and testing at present).

[brentzundel]

@jyasskin there have been significant changes to the charter since this issue was raised.
Are there further changes you believe need to be made, or has this issue been addressed?

[jyasskin]

@brentzundel I think it depends on what the WG wants to do with fields that contain a URL that software is expected to interact with. If https://en.wikipedia.org/wiki/Main_Page and https://example.edu/exchanges/refresh-degree/ aren't equally valid values for a field, then the normative definition of the field needs to define why one isn't valid, and what software is expected to do when it finds such an invalid value. That sounds like it'll need a definition of the protocol the URL points to.

• If the WG doesn't want to define that protocol yet, it should plan to omit that kind of field from the standardized data model too.
• If it plans to include that kind of field in the standardized data model (and if I haven't misunderstood how these fields interact with software), the charter should put protocols back into scope. It'd be fine to have them in the "Conditional" section, but if they don't actually get published by the VC2.0 REC, the associated fields also shouldn't appear in that REC.

[iherman]

The issue was discussed in a meeting on 2022-03-16

• no resolutions were taken

View the transcript

4.2. Be clear that defining some fields means defining the ceremonies they point to (issue vc-wg-charter#68)

See github issue vc-wg-charter#68.

Brent Zundel: Can anyone get on the queue to talk about this.

Manu Sporny: Jeffery's point is that if we are going to define a field like "status" or whether a credential is revoked or suspended or whatever. If there's a protocol that goes along with the data model thing, define the protocol as well. To not do it is dangerous. I agree with him, but there are scoping decisions around not doing protocols yet.
… I think that's where we are. Jeffery would like us to put protocols in scope. They aren't in scope normatively, but to talk about non-normatively. That's the best the group can do now.

Dave Longley: I'm trying to remember, with changes made to charter, we will take on work w/ CCG as we decide it'll become mature to do so, does this solve that problem?

Kristina Yasuda: Jeffery's initial comment, I think, was inspired by VC refresh. Where do we stand with that? Will we be normatively defining that if we want to or can we only just talk about it?

Manu Sporny: I think where we are, Kristina, if that we have been traditionally able to talk about the data model. It's possible in the VCWG 2 group we can talk about it but not normatively define it. It's part data model and part protocol. There's no input document listed for refresh or status list because we put protocol out of scope.

Kristina Yasuda: I think your comments that refresh is both on data model and protocol leaves it open as to what to do with it.

Manu Sporny: Well, we can't work on the protocol parts, so we said that's out of scope. So the most we can do is publish that thing as a NOTE with data model and protocol.

Kristina Yasuda: Ok, I think that's a good clarification. For documents that have partially protocols in them -- we can do the data model normatively and the protocol parts non-normatively.

David Chadwick: If we have anything in our data model that is a URL does that imply protocol and we've now excluded that?

Brent Zundel: No. We can point to normative documents for dealing with URLs, it's right over there.
… We can't invent protocols.
… Thank you all for coming today and for the progress we've made.
… Please get into the issues we need to do more inter-week processing in issues to get these cleared out.
… Thanks all for being fantastic!

---

[kdenhartog]

Reading through the notes from the last WG meeting here, I'm struggling to comprehend what additional interoperability are we getting by only standardizing the refresh data model and credential status data model while leaving the subsequent ceremonies/protocols non-normatively defined? Isn't this just going to lead to an implicit divergence in these bodies of work instead by not defining the protocols with the data model? To me that seems like it would be taking us a half a mile closer to standardization when we only have a mile left to go for this area of the work and it's at the cost of an entirely new document.

[msporny]

To me that seems like it would be taking us a half a mile closer to standardization when we only have a mile left to go for this area of the work and it's at the cost of an entirely new document.

The unfortunate reality is that there is at least one member in the VCWG that would formally object if we put protocols in scope. Some of that objection is well founded -- we're already taking on a lot in the VC2WG and the VC API isn't completely incubated (though, it's probably good enough at this point to go into a 2 year WG -- if that's all the WG would focus on). Paths that could achieve consensus moving forward include:

1. Defining only the data model and not defining any part of the protocol (this is what you're concerned about above).
2. Defining the data model normatively, and leaving the protocol non-normative (e.g., status - https://w3c-ccg.github.io/vc-status-list-2021/ and credentialRefresh - https://w3c-ccg.github.io/vc-refresh-2021/ -- but with no normative statements about the protocol bits).
3. Defining the data model and protocol normatively, but outside of the VC2WG for now to get more implementer experience.

I think many in the group are planning to do # 3 above, which isn't terrible, and feels like the responsible thing to do (give these things another year or two to breathe). To move any faster, we'd need more editors, implementers, and test suite writers than we have right now.

@jyasskin, I think the above is one potential answer to your suggestion above. Thoughts?

[jyasskin]

@selfissued How would you feel about including at least some protocol work in the Conditional Normative Specifications section of the charter? That would allow the group to pick up some of the protocols if they make more progress than you're expecting, while not committing the group to do work if the current incubation (which I think is what @msporny is referring to with (3)) proceeds slowly.

Continuing to use refreshService as an example, if the protocol doesn't make it to PR (or another state acceptable to https://www.w3.org/2013/09/normative-references) with the rest of the VC document, I'd hope that the definition of the refreshService field itself would also move to the document defining its protocol.

I won't push for a formal objection from Google on the charter if it leaves protocols/ceremonies out of scope, since it seems like the WG could still produce a useful spec by moving the relevant fields to incubation documents. (Even though I see the WG is reluctant to do that.) I would consider formally objecting to a final specification that includes these fields but can't normatively reference a complete definition for them. Even with a non-ideal charter, we have some time to work that out.

[brentzundel]

I think we have done everything that we can to cover this in the charter, the rest will need to be done by the next WG.
Closing the issue.

@jyasskin We would welcome your participation in the WG to help ensure that the specification it produces isn't something you would object to.