WebID Extension Profiles Nomenclature?

[melvincarvalho]

How will WebID Extension profiles be named?

Will it be for serializations?

WebID-JSON-LD WebID-Turtle ...

For features, e.g. auth:

WebID-auth-TLS WebID-auth-OIDC ...

And so on?

How to get started on such a document -- does it need to be bikeshed?

[jacoscaz]

/chair hat on

For context, implementability concerns expressed in #3 , #17 and other places indicate that the best chance at moving forward is through a new 2024 ED with a MUST on JSON-LD and Turtle for publishers. PR #45 , which represent the first significant change to the working draft in a long time , was crafted and merged on the basis that the 2014 ED is to be considered as frozen in spec/drafts/ED-webid-20140305.

Effectively, this negates the need for "format" Extension Profiles. Thus, this issue should be narrowed to discussing the nomenclature for feature Extension Profiles, which should be the only type of Extension Profile that the spec needs.

[melvincarvalho]

__

For context, implementability concerns expressed in #3 , #17 and other places indicate that the best chance at moving forward is through a new 2024 ED with a MUST on JSON-LD and Turtle for publishers.

Please take into account the strong objection and call for a freeze of WebID 2014 ED here

I dont really feel that I have been heard on this, despite the repetition. So I would like to again emphasize strong objection. I dont think the group should focus on highly controversial things. Removing turtle=MUST is highly controversial, introducing conneg as MUST is even more controversial. This has been the case for many years, as evidenced by the permathreads on it. That circle cannot be squared.

That said, after the Solid WG is up and running. The picture will be clearer. The Solid WG can articulate their needs, and the CG can work hand in glove.

Effectively, this negates the need for "format" Extension Profiles. Thus, this issue should be narrowed to discussing the nomenclature for feature Extension Profiles, which should be the only type of Extension Profile that the spec needs.

So what is needed to progress is the name of the feature

WebID-auth-TLS WebID-auth-OIDC ...

What is also needed is some pointers on how to do so. Could a request a blank "template", say, using bikeshed, as a means to make progress.

[jacoscaz]

/chair hat on

Please take into account the strong objection and call for a freeze of WebID 2014 ED here

I'm not sure I understand, @melvincarvalho . The 2014 ED remains untouched in https://github.com/w3c/WebID/tree/main/spec/drafts/ED-webid-20140305 . I'm not aware of anyone who's proposing to make changes to that document.

[melvincarvalho]

which represent the first significant change to the working draft in a long time

OK, this is very controversial, and I dont think it should be taken on at this time. Removing Turtle=MUST is controversial, I couldnt live with that change either. Adding conneg as a MUST of publishers is even more controversial, that I could not live with. WebID ED is in use, and I think 2024 vs 2014 would simply confuse matters. I would prefer to hear what the upcoming solid WG think first. I would kindly ask you not to keep making me repeat this objection, and to take into account when choosing what to work on. I would also be happy to revisit this once the Solid WG is announced, hopefully quite soon. I dont think the CG should be taking on such highly controversial items right now, without consensus of the full group and also of those who are using the system.

All that said, any advice, vague pointers, or hints on how to create WebID extension profiles would be invaluable at this stage. Even a consensus on naming features.

[jacoscaz]

/chair hat on

I would kindly ask you not to keep making me repeat this objection, and to take into account when choosing what to work on.

@melvincarvalho I am only trying to understand.

Insofar as I could tell up until a moment ago, you were objecting to changing the 2014 ED, and I pointed out that nor I nor anyone I've recently interacted with wanted to do so. For reference, the 2014 ED lives in https://github.com/w3c/WebID/blob/main/spec/drafts/ED-webid-20140305/identity/index.html .

However, from your last comment I now understand that you're objecting to changing the working draft itself (for reference: https://github.com/w3c/WebID/blob/main/spec/identity/index.html), even if we were to do so within the context of working towards a new and separate 2024 ED. You're not proposing a freeze of the 2014 ED, you're proposing a freeze of the working draft to keep it from deviating from the 2014 ED. Is my understanding correct?

[woutermont]

Not sure what you're asking for here...

• An extension profile mechanism can be proposed as a change when there is a use for it. The only place I can see relevance for it a.t.m. is to allow for authentication mechanism extensions. But like I said, that should just be proposed and processed as any other change, and we have not yet started on that. I would also suggest to first focus on merging those changes on which we have reached consensus in the past months.

• All the changes we talk about are aimed at the working document (top-level in this repo), which is always dated according to the latest change, currently 2024-1-26. There won't be made any changes to the latest 2014 draft.

[melvincarvalho]

@melvincarvalho I am only trying to understand.

clarifying

Insofar as I could tell up until a moment ago, you were objecting to changing the 2014 ED, and I pointed out that nor I nor anyone I've recently interacted with wanted to do so. For reference, the 2014 ED lives in https://github.com/w3c/WebID/blob/main/spec/drafts/ED-webid-20140305/identity/index.html .

Yes

However, from your last comment I now understand that you're objecting to changing the working draft itself

Yes.

you're proposing a freeze of the working draft to keep it from deviating from the 2014 ED. Is my understanding correct

Yes. Complete freeze.

I am opposed to changes at this time. I have given lots of reasoning. I would like to state very strongly and emphatically how opposed I am to changes, because I dont think I've been heard, despite posting multiple time on several issues, on the ML, rephrasing, clarifying. I dont know what more I can do. Each time I state it, I feel i have to do so more forcefully. It's frustrating and tiring to repeat, please take this strongest possible objection into account. Conneg is also an absolute NO for me. I cant live with this, no.

One big problem is that you didnt state exactly how you wanted to make changes, e.g. you could have asked to make a breaking change, and bumped the version to 2.0 but that didnt happen, its more like asking for a blank check.

Another thing is that the Solid WG are expected to take WebID ED 2014 to possibly REC after they start, and there is no sense of buy in from them, right now.

I am happy to work on the agreed time of superset and subsets, which was uncontroversial and had a large amount of support. I would like to know how to make progress and create implementations. But we are side-tracked on highly controversial items that have not had consensus in years. I can wait but any guidance at this point it helpful.

[melvincarvalho]

• An extension profile mechanism can be proposed as a change when there is a use for it. The only place I can see relevance for it a.t.m. is to allow for authentication mechanism extensions.

Simply getting the ball rolling, by figuring out naming, hence nomanclature

• All the changes we talk about are aimed at the working document (top-level in this repo), which is always dated according to the latest change, currently 2024-1-26

It's not a living standard, it's in use. At least bump the major version number. Bumping the date is not enough.

[woutermont]

I still don't see how you can come up with nomenclature for something that has not yet been proposed. Typically, profiles of a spec ABC are called ABC profiles or, of multiple features are being profiled, ABC FeatureX profiles. If and when we profile authentication mechanisms, they would thus probably be called WebID Authentication Profiles, with WebID-TLS being one of them, and WebID-OIDC a possible other.

[woutermont]

As for your concerns around versioning: major versions should indeed be used for breaking changes, but there are a number of caveats here:

• This only holds for people published recommendations, while WebID is just a draft. Currently, we are the Jan 26th 2024 draft of WebID v1.0.

• The changes we are making are not breaking for existing clients. Through conneg, we remain backwards compatible. So there is really no need for a major version bump.

If this remains a concern, we might perhaps reach a middle ground by adding the draft date explicitly to the version number, as v1.0-20240126. That way, we have a correctly increasing semantic versioning number, without somehow claiming to be the second version of a never published technology.

[melvincarvalho]

If this remains a concern, we might perhaps reach a middle ground by adding the draft date explicitly to the version number, as v1.0-20240126

-1 no, cant live with that, it's misleading and taking something existing, stable, in use for a decade and trying to make it a living standard

Glad I piped in here. I reiterated WebID is not a living standard. It was considered stable and finished.

[melvincarvalho]

The changes we are making are not breaking for existing clients. Through conneg, we remain backwards compatible. So there is really no need for a major version bump.

It's actually a MASSIVE breaking change. It essentially ruins a fairly decent spec. I'd even go as far as to say the breakage is so great it should not even have "Web" in the name.

[jacoscaz]

I am... at a loss for words. I will wait for others to pitch in. It might be time for me to resign and call it a day.

[woutermont]

I reiterated WebID is not a living standard. It was considered stable and finished.

I never said it was. I just say that what we change is a DRAFT, which is a living document until it is published as a recommendation.

Adding a date or other increasing specifier to the end of a version number is a correct semantic version increase, respected throughout the whole development world.

It's actually a MASSIVE breaking change.

If you believe that, I'm not sure you fully understand what a breaking change is. A breaking change is a change that makes existing software interacting with yours break. But like I repeatedly pointed out, every client that works with the 2014 draft will still work with the 2024 one. That is precisely why we put the burden of the change on the WebID host by introducing conneg. An application will never even know whether it is talking to a 2014 compliant host or to one that follows the 2024 draft.

[melvincarvalho]

I am... at a loss for words. I will wait for others to pitch in. It might be time for me to resign and call it a day.

@jacoscaz thank you for listening to the objections. This has been a controversial topic for several years. Especially conneg. Hence reaching an impasse.

We did say that the subset/supeset spec with extensional profiles was a non-controversial way to break the impasse, which is what I thought we would do and solve the WebID problem for everyone. I appreciate the big steps we've made in that direction. This thread was simply about trying to agree on common naming conventions.

What happened was a pivot back to what has been a highly controversial topic for many years. I was simply pointing out that it is still controversial.

There are several ways forward:

1. complete extension profiles giving everyone what they want, with broad consensus and mandate
2. wait for solid WG to start up and gain a real consensus on what they want, and if they want and to be part of a WG
3. work on a new spec with breaking changes, with a full version bump, it should be absolutely clear that it's a new spec, and not trying to turn the existing spec into a living standard

These are all reasonable, and known things. I am sorry if you felt there was consensus on introducing conneg. There isnt right now. You yourself know that conneg is a breaking change, it breaks all standalone WebID profiles that exist today, possibly forever. And introduces impossible to comply with rules evidence by the conneg implementations all having huge sources of bugs, and being a performance disaster.

Plenty of paths forward, I suggest be patient, and tackle the less controversial items. Taking on a 10 year old stable spec with existing adoption was NEVER going to be an easy path.

[melvincarvalho]

I just say that what we change is a DRAFT

It's much more than that. It's only a draft because we didnt add it to LDP. During all the initial Solid meeting at MIT and else where it was considered a done deal and stable. Nothing really to add to it. Eco systems were built up around this stability. Portraying it as a draft is not accurate. And trying to take it and apply changes to it, is going to have push back. Making a clear new version of it, will have a better chance.

[melvincarvalho]

If you believe that, I'm not sure you fully understand what a breaking change is.

OK, I'm going to end this conversation here because I like you and I dont want it to become adversarial. If I have an existing webid profile.ttl today it would work just fine. But after the breaking change forcing conneg, for the vast majority of web servers in existence, it would break WebID. We can agree to differ on this one. It's a huge implementation burden on the server side.

[woutermont]

These are all reasonable, and known things. I am sorry if you felt there was consensus on introducing conneg.

These might be reasonable to you; they might not be to other people.

In particular, or is not your mandate to sense the consensus in the group. @jacoscaz is the current chair, and he feels there is consensus. Rightly so, in my opinion, because there has been lots of acknowledgement from everyone except you.

Also, you clearly do not understand extension profiles. I suggest you (re)read the W3C Spec Variability note. Such profiles can insert degrees of freedom, but break interoperability. For authentication mechanisms, this is not necessarily a problem, but for serialisations it is. Therefore, profiles for different formats is not a solution.

[woutermont]

Btw: what do you suspect the Solid WG will do when they finalize WebID? Call it WebID 2.0? Of course not. They will publish the first version of the WebID recommendation: W3C WebID 1.0.

[melvincarvalho]

In particular, or is not your mandate to sense the consensus in the group. @jacoscaz is the current chair, and he feels there is consensus. Rightly so, in my opinion, because there has been lots of acknowledgement from everyone except you.

I dont think this is accurate. The topic has been controversial for years. Ironically, no one pushed for change more than me, and in fact Henry did push back several times. I find myself now arguing Henry's case. This has never been uncontroversial. Im simply pointing out what has always been the case, that this is controversial.

I think the nature of part of it is that there is a certain group that is dismissive of the burden of conneg. And a broader web group that does not want to do conneg. It should however be uncontroversial and objective that conneg is a breaking change.

[melvincarvalho]

The lightest thing that I think could be done that MIGHT not be a breaking change, would be to replace all the 19 RDFa references with JSON-LD (without MUST).

The way to do this in a non-breaking way is to agree the serialization agnostic WebID definition (superset) and then have specific profiles that anyone can use for either preferred serialization(s). Or features (auth / authn / authentication).

We just need to agree on a preferred naming system, and a way to get the ball rolling so that we can make implementations, gain adoption, write apps, and so on...

[woutermont]

I've responded in https://github.com/w3c/WebID/issues/58 to center the discussion again and leave this thread for its own purpose.

[TallTed]

@melvincarvalho —

Portraying it as a draft is not accurate.

You continually insist on this. Your statement is what is not accurate. The WebID 2014 ED (Editor's Draft) is and always has been a DRAFT, no matter that it has lain fallow for most of a decade.

Please stop insisting that a falsehood is a truth, so we can move forward.

[melvincarvalho]

Thanks for the feedback.

This thread has been inconclusive.

Assuming a serialization neutral WebID definition will emerged in the future, it seems sensible to proceed with a JSON-LD extension named:

WebID-JSON-LD

Closing