specification
specification copied to clipboard
solid
Bump Solid Protocol to 2.0 for the indirection between WebID and Solid Profile
Traditionally, a person's WebID (like https://alice.example.net/card#me ) was an ID in their profile document (like https://alice.example.net/card). The WebID is the value returned by the login process.
WebIds are used throughout as the identity. For example, Authentication systems use the webid in Authorizations.
Applications look up the profile to look up basic information basic information about a person (like avatar and nickname) and also a route to indirectly find all kinds of related information public and private. Applications also can help the user edit their profile information, and so on.
A more recent requirement from the SolidOIDC work, to separate identity and storage, is that the webID produced by the login process is NOT a user-editable profile document, but has a link to it. So any app following the webid to the profile has to follow that link.
This represents a big change to the ecosystem, so I propose it be recognized by bumping the solid protocol version from 0.9.x to 2.0.0. I suggest skipping 1.x as "version 1" has connotation in some circles which would be misleading.
For an implementation that has triple-level resource access control, what requirements would this spec change impose?
@gibsonf1 Is that a future or current implementation (do you have pointers)?
A more recent requirement from the SolidOIDC work, to separate identity and storage, is that the webID produced by the login process is NOT a user-editable profile document, but has a link to it. So any app following the webid to the profile has to follow that link.
AFAIK this doesn't come from Solid-OIDC spec, more likely from a specific deployment using it. Solid-OIDC still works based on solid:oidcIssuer designation and it doesn't couple the login process with the creation of WebID. How WebID Document gets created and where it is hosted is out of scope for Solid-OIDC.
The separate profile document seems to be specified in https://solid.github.io/webid-profile/
@RubenVerborgh All the TrinPod servers have triple level access control such that only solid required public triples are public view keeping all other webid triples private: https://frederick.trinpod.us/i So a current implementation (launching soon)
I agree with @elf-pavlik that this question is orthogonal to Solid-OIDC which can operate with either a directly dereferenced WebID or one that requires a second document. The idea is to separate identity and storage, but not because of Solid-OIDC.
My understanding is that the change was introduced because server implementers decided that it was their right and more secure to restrict access to the WebID document. In addition there is the use case in which an identity provider handles multiple protocols and does not provide pod storage space. In that case also there would be valid reasons to store the WebID document in a way that is not editable using the Solid Protocol. This change in server implementation results in two different kinds of relationships between the WebID URI and the Solid Profile that need to be accounted for by clients and therefore @timbl's suggestion to bump the version number.
The change proposed by the Editors to https://solid.github.io/webid-profile/ is that we define a Solid Profile as a set of triples editable by the Solid Protocol whose starting point can either be dereferenced directly from the WebID URI or by following a solid:profileDocument link in the graph dereferenced from the WebID URI. This definition does not introduce the split between direct and one-hop away profiles, it only clarifies that, when there is such a split, there should be a single specific link between the two and that the Solid Profile be editable by appropriately authorized Solid apps. Without such a definition, we are, in my opinion, in the wild west - servers get to decide what a Solid Profile is and apps have nothing to say about it.
@gibsonf1 - since the triples in a Trinpod Solid Profile are a) retrievable by dereferencing the WebID URI and b) editable using the Solid Protocol, it already matches the these changes and I do not see that the change would have any impact on Trinpod (or for that matter, NSS or CSS AFAIK).
"separate identity and storage" - I would phrase that more as "separate the identity that is provided by and recognized by the verifying entity from the identity as described by the agent themselves". The first kind of identity "belongs" to both the verifying entity and the agent while the second kind of identity MUST (in my opinion) belong exclusively to the agent and be editable by them using the Solid protocol.
@jeff-zucker Exactly, and there is always the option based on implementation that both are actually in the same place as well. A key issue is being able to make public only those webid triples that the user intends to have public, for which there are multiple solutions including triple-level resource acls.
Chiming in about the version number - we are currently operating under a 0.x release number, which leads me to believe the specification is still being developed and not final. In my opinion, even a big change would be ok to release in the 0.x versioning scheme since we are still fleshing out the specification and changes (big or small) are to be expected. For me, a 1.x release (or a 2.x for that matter) should happen once the specification has reached enough maturity to be marked as 'stable'.
Releasing this as a 2.0 would lead me to believe a couple of things:
- this is a release that is stable enough to warrant a number that doesn't start with 0.x.
- there was an idea for a 1.0 version which was scrapped and unreleased for whatever reason.
In the end it is just a number to identify a release, but I would have no issue with having this change released as 0.10.0.
I propose it be recognized by bumping the solid protocol version from 0.9.x to 2.0.0.
Can we please not do this and just go with 0.10?
Especially as "version 2" has connotation which would also be misleading (like the spec being stable/finalized).
Besides this, the specs currently do not have a method for apps to ask a solid server which version they support (and no way for servers to state this), making it impossible to have support for both v2 and non-v2 implementations. To me, that means we are still in the "move fast, break stuff" phase of the specs. Not the 1.x, 2.x, or any other version beyond 0.x.
I have been persuaded that bumping it to 0.10.1 is ok, as we are in a pre- 1.0 spaces where you indicate an incompatible change with a minor version bump not a major one because that is how semver works. I am still concerned about the incompatibility.
There seem to be two incompatible Solid forks, one on identity, and another on authorization
Having a "big tent" approach in 0.10.x, might work
However 4 potentially incompatible ecosystems, under the same version number, probably would benefit some further explanation, or sub divisions
Closing issue as commenter satisfied - original proposal withdrawn in favour of 0.10: https://github.com/solid/specification/issues/461#issuecomment-1287502961
