The WG may produce registries

[brentzundel]

This PR takes one part of PR #85 which I hope will achieve consensus.

---

Preview | Diff

[msporny]

I would personally like to be more specific, but would be fine w/ this text as well.

[msporny]

Suggested change

	to support extension points in the above normative deliverables. Registries for
	extension points that are required by any of the above normative deliverables
	must have at least one standardized entry.
	to support extension points in the above normative deliverables. Registries for
	extension points that are required by any of the above normative deliverables
	must have at least one standardized entry.

-1, I expect that we'd have to remove features in the VC spec and that would be controversial.

[msporny]

Hrm, on second read, I'm confused. So, existing extension points that don't have normative registry entries would still be allowed?

[brentzundel]

I tried to add the language that seemed to have the most consensus during the WG call on March 2nd.
Currently, the only normatively required extension point in the VC data model is 'proof', which we will standardize in the data integrity work. I don't see any features that we would need to remove. What am I missing?

[msporny]

I don't see any features that we would need to remove. What am I missing?

We currently don't have normative deliverables in the current charter defined for any of the following extension points:

https://www.w3.org/TR/vc-data-model/#status
https://www.w3.org/TR/vc-data-model/#evidence
https://www.w3.org/TR/vc-data-model/#terms-of-use
https://www.w3.org/TR/vc-data-model/#refreshing
https://www.w3.org/TR/vc-data-model/#data-schemas

One reading of the language wrt. "normative registry entries" is that every single one of those features should be removed in the VC 2.0 work, which I expect would lead to objections from organizations relying on those extension points out in the field.

[brentzundel]

none of those are required by the VC data model, therefore none of those would need a standardized entry in a registry.
But also, the language has been removed form this PR and moved to #101

[msporny]

none of those are required by the VC data model, therefore none of those would need a standardized entry in a registry.

Ah, I see, and am now slowly remembering the conversation... I'm not opposed IF everyone reads the language in the same way. I'll try providing some changes in PR #101 to try to make it clear that it only applies to normative properties... though, I expect, this wouldn't address @jyasskin's concern.

[msporny]

I was supportive of this PR, but now am not given the recent change in 6753b9e and confusion in #98 (comment).

[brentzundel]

@msporny since the original intent of this PR was to try and find consensus on the WG having any registries, I have removed the controversial change and will reintroduce it in another PR

[selfissued]

This is great! This is all we need to say about registries in the charter.

[iherman]

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

• no resolutions were taken

View the transcript

1.2. The WG may produce registries (pr vc-wg-charter#98)

See github pull request vc-wg-charter#98.

Brent Zundel: looks like we have rough agreement, we want registries in the charter for the most part.
… can you throw your approval instead of the stale CR, any opposition to merging this PR.

Joe Andrieu: I oppose, for reasons stated.

Brent Zundel: Joe your opposition is noted, and will go into the comments on the PR.

Oliver Terbu: does registries include data integrity proof registry, my concern is it should be permissive enough, and if we can get that right then I'm on board.

Manu Sporny: +1 to registry not being restrictive... it needs to be permissive..

Brent Zundel: the charter doesn't restrict as of yet but the vcwg may restrict at a later date.
… over the noted objection from joe will merge the PR.
… two other PRs that build towards what 85 was aiming for, looking at 99 next..