Consider adopting WebID 1.0 ED as a Deliverable

[csarven]

I propose that the Solid WG charter should adopt the WebID 1.0 ED as a Deliverable, if of course the WebID CG agrees.

There is plethora of publishing and implementation experience, as well as use of WebIDs in the wild, I would strongly suggest that the Solid WG should only focus on translating Web 1.0 ED - what is seemingly a document equivalent to the maturity of level of a Proposed Recommendation, that's been around forever but needs some love - to a REC. I would also suggest that the specification should not introduce breaking changes, and should continue to stand on its own. The specification is currently developed at https://github.com/w3c/WebID/ .

IMO, this would undoubtedly be mutually beneficial for the WebID CG and Solid CG/WG, as well as other Groups, and the WebID-based ecosystems that use the specification today.

---

As the Scope/Out of Scope section is written in https://github.com/solid/solid-wg-charter/pull/38 , I would not consider WebID to be out of scope. However, if an agreement can be reached, we should update the Scope and Deliverables section to clarify that.

[melvincarvalho]

If my recollection is accurate, the integration into the LDP charter was nearly achieved, but ultimately it wasn't included. Logically speaking, it might be appropriate for it to be a part of Solid, given this is its origin.

[bblfish]

yes, that makes sense.

[langsamu]

I support this proposal.

I am the lead contributor to recent commercial implementations of WebID and ACP, and a contributor to recent commercial implementations of the Solid Protocol and Solid-OIDC.

My experience is that WebID is practically, if not theoretically, indispensable for Solid. For this reason I should think the working group is highly incentivized to adopt it. I would consider the effort an excellent investment.

I also think that the draft is implementable as it stands. Not just on its own but as part of the wider context I have experience developing and supporting. Hence I agree that the effort should be restricted to translating the draft to a recommendation.

If only I never again hear the words "but it's just a draaaaaft".

[pchampin]

What is the relation between the WebID CG's ED WebId and the SOlid CG's report Solid WebId Profile? Seems to me that if they were to be adopted by the Solid WG, they should be merged into one document?

Also, I have mixed feelings about this. One the one hand, recall that this WG is meant to focus on the client-to-server interactions (the Solid Protocol per se), as opposed to the client-to-client conventions (vocabularies, shapes...) that are also part of the full Solid landscape. On the one hand, WebID seems to belong to the 2nd category. On the other hand, as @langsamu points out, it is so core to everything in Solid (starting with authentication, if I am correct?), that having a standard Solid Protocol without a standard for WebID seems strange.

[elf-pavlik]

Following my reasoning in #37 we seem to have two choices

1) Adopt WebID draft as a Solid WG working item 2) Work on changing Solid Protocol to remove WebID as a Normative Reference

In WebID spec I counted all the normative MUST requirements:

Turtle

A WebID Profile Document is a Web resource that MUST be available as text/turtle [turtle], but MAY be available in other RDF serialization formats (e.g. [RDFA-CORE]) if requested through content negotiation.

The server MUST provide a text/turtle [turtle] representation of the requested profile. This document MAY be available in other RDF serialization formats, such as RDFa [RDFA-CORE], or [RDF-SYNTAX-GRAMMAR] if so requested through content negotiation.

WebID requires that servers MUST at least be able to provide Turtle representation of profile documents, but other serialization formats of the graph are allowed, provided that agents are able to parse that serialization and obtain the graph automatically. HTTP Content Negotiation can be employed to aid in publication and discovery of multiple distinct serializations of the same graph at the same URL, as explained in [COOLURIS]

The Requesting Agent needs to fetch the document, if it does not have a valid one in cache. The Agent requesting the WebID document MUST be able to parse documents in Turtle [turtle], but MAY also be able to parse documents in RDF/XML [RDF-SYNTAX-GRAMMAR] and RDFa [RDFA-CORE]. The result of this processing should be a graph of RDF relations that is queryable, as explained in the next section.

HttpRange-14

WebID A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, Device, etc.). For WebIDs with fragment identifiers (e.g. #me), the URI without the fragment denotes the Profile Document. For WebIDs without fragment identifiers an HTTP request on the WebID MUST return a 303 with a Location header URI referring to the Profile Document.

Github repo currently has 6 open issues, with just a few of them on the normative parts of the spec itself

• https://github.com/w3c/WebID/issues/3
• https://github.com/w3c/WebID/issues/10
• https://github.com/w3c/WebID/issues/16

[csarven]

The Solid WebID Profile specification is about the discovery and data model of WebID that's used in Solid, whereas WebID is the identification mechanism.

I strongly believe that Solid should keep WebID and Solid WebID Profile separate as they address different areas.

Having WebID in Solid WG is also strategic. Besides WebID being integral to the Solid ecosystem, it acts as a service to various communities, including research and deployment in the wild. As mentioned, the Solid WG would take on the responsibility to have it go through the Recommendation track. The Solid WG would be the most suitable WG for it at this time, and it may be unlikely for it to be picked up by another WG anytime soon. And, yes, Solid needs it, so why not?

---

None of those open issues on the normative parts of the WebID spec were detriment on WebID's adoption, including the whole Solid ecosystem. The issues postdate. Whoever resolves them to improve the spec, great! As it stands, none of them are show stoppers as I see it - those issues could be dropped altogether.

[jeff-zucker]

What is the relation between the WebID CG's ED WebId and the SOlid CG's report Solid WebId Profile?

The WebID spec defines what a generic (not Solid-specific) WebID is. The Webid-Profile spec defines how a WebID is used in Solid and specifically, the organization and purpose of the Solid WebID Profile. The relationship between a WebID Profile Document (which may or may not be on a Solid Resource Server) and a Solid Profile is part of what the CG is working on.

[jeff-zucker]

I agree that the WG should take on the WebID 1.0. ED as a deliverable.

[jonassmedegaard]

Sounds good to me to pass on governance of WebID spec to the Solid working group - in case my voice here matters.

[melvincarvalho]

@elf-pavlik

A WebID Profile Document is a Web resource that MUST be available as text/turtle [turtle], but MAY be available in other RDF serialization formats (e.g. [RDFA-CORE]) if requested through content negotiation.

This was the definition about 10 years ago. There has been a lot of modernization since then and discussions in the CG. In short JSON-LD has matured and gained significant adoption in the intervening time period.

Recent consensus has gravitated towards using Turtle and JSON-LD as the primary serializations, a direction which I believe is in harmony with Solid's approach. If needed, we can initiate a brief discussion thread within the CG to affirm this understanding (i.e., Turtle + JSON-LD).

[melvincarvalho]

FYI: the WebID CG is currently developing a document that reflects our collective consensus from 2014 to 2023. For instance, we've agreed unanimously and without objection that JSON-LD should be mentioned in light of its significant deployment post-2014 ( https://lists.w3.org/Archives/Public/public-webid/2020Aug/0000.html ).

We are working through a temporary challenge with chair responsiveness, as we currently have only one chair. However, the group is actively looking for solutions, to this issue.

But, I'm optimistic we can collaborative to produce a specification that is agreeable to all. Perhaps we'll need a bit of interaction between the start of the WG and FPWD, depending on how quickly things go.

[bblfish]

It think we agreed that JSON-LD is a good addition. Why not just wait for the Solid WG? JSON-LD is already part of LDP, so it wouldn't be a problem. Those who want to deploy with json-ld already are welcome to do it.

There is also a WebID GitHub repo and updates have been made there to the spec in the last year.

[melvincarvalho]

@bblfish

Our group has transitioned to a 'lazy consensus' approach for decision-making to ensure the diverse views of all members are represented. Please refer to this for more detail: https://lists.w3.org/Archives/Public/public-webid/2023Jul/0042.html.

[bblfish]

Melvin, you agreed to the move to the WG on June 1st here

https://lists.w3.org/Archives/Public/public-webid/2023Jun/0000.html

We left everybody time to answer and I did not see anyone against this move, hence the commit here.

[melvincarvalho]

The commit is fine. I am pointing out some new information, that the consensus of the group, particularly for the years 2014-2023 is being documented, in preparation, to work together with the solid WG. And that the group has moved to lazy consensus. The current consensus is coalescing around an idea that could potentially please everyone in the WebID CG and in the Solid WG:

https://lists.w3.org/Archives/Public/public-webid/2023Jul/0056.html

[jacoscaz]

Hi all, and particularly @csarven .

In the WebID CG group we're trying a new approach to get out of the long-standing impasse. Tracking the conversation across both GitHub and mailing lists is hard and time-consuming, so I thought I'd provide some context here and invite feedback from the Solid WG.

Quoting my comment from https://github.com/w3c/WebID/issues/21#issuecomment-1829403570 :

Here's a few links that might help to contextualize this:

New chair: https://lists.w3.org/Archives/Public/public-webid/2023Nov/0121.html Nathan's superspec/subspec proposal: https://lists.w3.org/Archives/Public/public-webid/2023Jul/0056.html , originating in https://github.com/w3c/WebID/issues/17 Super-early superspec draft: https://jacoscaz.com/WebID/superspec/webid.html

Fundamentally, the idea is to produce a minimal WebID "superspec" (I think another word to describe it would be a framework spec) focusing on the underlying concepts and mechanisms of WebIDs while leaving serialization formats (Turtle, JSON-LD, ...) and specific features (TLS, OIDC, ...) up to subspecs.

The end result should, of course, be functionally compatible with the current version of the spec. The intention is not to create something functionally different but, rather, to re-organize the spec so as to overcome the current impasse and finally get to WebID 1.0.

Amongst other triggers, all this was prompted by the Solid WG intention of taking over the WebID spec, given the long wait for WebID 1.0: https://github.com/solid/solid-wg-charter/issues/39 . I don't mean this in a bad way, I actually think handing everything over to the Solid WG group is a good idea. But, there is tangible consensus around the superspec/subspec approach and it does feel worth a try.

As one of the primary implementors of WebID, feedback from the Solid WG is particularly welcome.