Single Extension Point

[David-Chadwick]

Here is a radical proposal which simultaneously simplifies the data model and removes all arguments about which extension points to keep and which to move to a reserved list.

DELETE THEM ALL AND REPLACE THEM WITH A SINGLE EXTENSION POINT

The single extension point can be regarded as the supertype of all the existing extension points. The only mandatory parameter of the extension point is the type, and this must be a URI. After that, all the following parameters are determined by the type. The existing defined types for all the existing V1 extension points can still be used in the new generic extension point, since they are globally unique URIs. Hence their existing definitions will not change. All that changes is the definition of the new wrapper parameter. Instead of being ToU, or Evidence or whatever, it becomes extensionPoint. In this way there is no need to ever define a new extension point. The extensionPoint parameter can be used for all of them.

P.S. This is not a new idea, it's the existing standard X.509v3 model which has been proven to work.

[decentralgabe]

Could you give an example @David-Chadwick? How is this different than using @context as a single extension point?

Do you mean literally have a property called extensionPoint that is an any container for extensions? What about multiple extensions? Is it an array? I think this kind of overloading may be confusing for implementers.

[selfissued]

I appreciate you think about alternatives and simplifications, David. However in this case, I think that developers would be more confused by mixing together fields with different characteristics into a single extension point. I'd rather that each field retain its own JSON member name and description.

[David-Chadwick]

Yes I mean having a single extension point calledextensionPoint. This is not confusing to implementors as the X.509 experience indicates. Rather it is more confusing to implementors to have several different flavours of extension points because then they have to decide which flavour to use for their new extension. When there is only one, then this dilemma does not arise. All extensions go in the same extension point. They are differentiated as now by their type parameter. This is in fact much easier for implementors to use because they simply need to look at the type of the extension and compare it their list of known extension types. A URI match means they understand the extension. An unknown URI means they do not. Today implementors have to repeat this code for each of the different flavours of extension point so is in fact more code than what I am proposing.
@selfissued If the descriptions of the extension points were solid and agreed upon then we would not be needing to add the wording that their definitions may change in future, as is currently being proposed for the reserved properties table. So I assert that having just one extension point with solid wording is much less confusing for everyone.

[brentzundel]

Chair hat off, I would not be in favor of this change.

[OR13]

I would not be in favor of this change.

[msporny]

-1 to an "extension point bucket" :P

[Sakurann]

there does not seem to be consensus to move in this direction.

[iherman]

The issue was discussed in a meeting on 2023-05-24

• no resolutions were taken

View the transcript

2.1. Single Extension Point (issue vc-data-model#1102)

See github issue vc-data-model#1102.

Kristina Yasuda: David Chadwick is looking to remove extension points and replace them with another approach.
… I think there are very strong voices against it.
… Anyone willing to lead this issue?

Michael Prorock: Frankly, I'd object to a change of this nature. Unless someone in the WG is willing to write a PR for this we should close it.

Dave Longley: +1 to close.

[iherman]

The issue was discussed in a meeting on 2023-06-07

• no resolutions were taken

View the transcript

2.4. Single Extension Point (issue vc-data-model#1102)

See github issue vc-data-model#1102.

Brent Zundel: now talking about 1102. Was discussed and no one liked the idea so it was marked pending close.

David Chadwick: Each of the extension points only get in if there are implementations but that the definitions could change.
… we already have a class of extension which have impls and have a unique URI.
… if we have the concept of a single extension point and all others have their own URI but be under the single extension point.
… don't need the outer wrapper.
… if you have vague extensions that don't fit specific items like "TermsOfUse" you don't know where to put it.

Orie Steele: David, we've made this easy for developers by bundling everything into the JSON-LD context.

David Chadwick: a single point makes it easier for developers to propose future extensions.

Orie Steele: We kinda already do have the concept of a single extension point... its called @context, and nobody understands it, and its values are not normative.

Orie Steele: You just need to learn how to use JSON-LD to write conformant extensions, which is super easy.

Brent Zundel: chair hat off, I would not be in favor of this change. It is not less confusing. Implementers have a small set of extension points that are well define is the better option.
… chair hat on, we have recorded that several members have said they would not be in favor of the change. Likely no consensus.

Joe Andrieu: +1 to all that, would also be opposed. Open ended extension mechanism exists in @context.
… agree with Mike Jones it feels more complicated having them all in one bucket.

David Chadwick: looking for technical reasons and haven't heard any.
… just that people don't like it.

Orie Steele: technical reason, we already have an open ended json-ld way to do this, adding another makes our spec even harder for people to understand or use.

Orie Steele: the fact that its not obvious that json-ld solves this, is shocking to me, given our entire data model assumes we are experts at JSON-LD.

Orie Steele: +1 joe.

Joe Andrieu: one of the technical arguments is that this mechanism already exists in @context.

Brent Zundel: it is clear, there is no path to consensus. Question to DavidC: do you plan to formally object is we close the issue?

David Chadwick: No I would not.
… would appreciate more technical arguments.

Dave Longley: If you want some incubation for your idea, create an extension in the @context that is a generic extension.

David Chadwick: Thank you Dave, that is a good idea.

Brent Zundel: Issue 959 back on the table.

[brentzundel]

No consensus to proceed with this, but it may resurface after incubation elsewhere.
Closing based on conversation in meeting yesterday.