The Future of the WebID Profile Specification

[jeff-zucker]

ODI has outlined a WebID specification based, according to Jesse on the idea that the existing draft spec "is not consistently implemented across severs."

The existing draft spec has only two statements that relate to servers. If there are arguments to omit or alter these statements, the appropriate place for that is a PR on the existing draft and, as an author/editor of that draft, I would welcome such PRs. Other than those two relatively minor statements, there is nothing in the existing draft that is required of servers and therefore nothing to "consistently implement". There also seems to be a mistaken impression that the current draft forbids storing WebID Profiles on non-Solid servers. It does not forbid this, and in fact provides mechanisms to make it easy for an app to handle the profile regardless of where it is stored.

The bulk of the existing draft covers these two issues

• how can a client app discover data in the profile
• how can a client app add data to the profile

Discovery

I have created an app which implements the current draft to discover WebID profiles and their contents. It managed to gather WebID Profile documents from almost 500 WebIDs located on many servers, mostly non-Solid. It does this by following the draft specs' recommendations on rdfs:seeAlso and foaf:primaryTopicOf which make the Solid capabilities of the server irrelevant to the discovery process. It was able to gather discovery links from both type-index and SAI style sites. If anyone wants to claim that the current draft is limited in terms of profile-based discovery, please submit a valid webID profile that this app can't handle.

In terms of specific discovery predicates, the current draft takes the position that solid:oidcIssuer is orthogonal - covered by a different spec and may be replaced or added to with other protocols so should not be mandated in the WebID spec. The same stance was taken in regard to SAI/type-indexes. The WebID spec does not need to weigh in on identity or organizational approaches. We did not put a must on pim:storage because having a WebID without a storage is a valid use case. Again, if there are counter arguments, issues and PRs are welcome.

The only discovery predicate with a MUST in the existing draft is pim:preferencesFile. It should be noted this is NOT phrased as a mandate for servers, rather mandates for clients, including how to add a missing preferencesFile. The fact that some servers do not provide a pre-provisioned link to a preferencesFile is not an indication that they do not implement this draft of the WebID profile. OTOH, the load-profile app mentioned above shows that 88% of WebID profiles that had a solid:oidcIssuer also had a pim:preferencesFile predicate, so the usage is widespread even if not universal.

Adding Data

Suppose that I want to use a Solid app to add a group of foaf:knows statements to my profile. If the profile is located on a non-Solid server, the only way I can do that is by finding a link from the profile to a resource on a Solid resource server. The link might be to a type-index or an authentication agent which then points me to a location I can write to. Or, according to the existing draft spec, I can use the predicates rdfs:seeAlso and foaf:primaryTopicOf to point from the profile to a potentially writable document on a Solid resource server. The current draft treats these as optional and makes no recommendations about how a non-Solid server treats the issue. I personally think that it is best practice for servers to include one of these predicates in profiles. A user could still leave the endpoint empty or protected, but there would at least be a known link to something potentially changeable by a Solid app.

Mandating a pim:storage predicate, as suggested in the ODI version, does not solve this issue. Knowing the storage is not sufficient for an app to follow its nose to a location it can leave things other apps can reliably know where to find. A seeAlso link can point to a specific, knowable location, greatly facilitating follow-your-nose.

The existing draft approach basically tells an app that wants to add data to a profile - try to write to the WebID Document itself, and if that isn't possible, find a link in that document to an extended profile document and follow it to somewhere you can write. This allows the spec to support both cases - of a profile that can and one that can't be written to by a Solid app.

Some believe that we should not support any kind of writing to the WebID document, as it poses a known security risk by changing the oidc:issuer. The draft spec takes the position that there are a number of ways to protect those and other triples without forbidding all writing to a profile; that control over a person's profile is the most basic form of control Solid offers and should not be abandoned because of one of many solutions to a potential threat.

All of the above is based on literally years of work on the draft spec. The detailed discussions we had on each and every one of these issues and which included @timbl is available right here, in this repo. I do not see a need for an additional spec and hope that any recommended changes be combined with existing work rather than replacing it.

[csarven]

Are you a client or server working with Solid WebID Profiles?
          |                                        |
         Yes                                      No
          |                                        |
   Read this spec                    Any server will do, mate. Most of
                                     this spec still applies for
                                     describing a Solid WebID Profile.

[elf-pavlik]

The existing draft spec has only two statements that relate to servers. If there are arguments to omit or alter these statements, the appropriate place for that is a PR on the existing draft and, as an author/editor of that draft, I would welcome such PRs.
[...]
Some believe that we should not support any kind of writing to the WebID document, as it poses a known security risk by changing the oidc:issuer. The draft spec takes the position that there are a number of ways to protect those and other triples without forbidding all writing to a profile;

If you remove those two requirements on Servers, which as of today have 0 implementations, how does Solid WebID proposal prevent this very clear security risk. I have a simple demo (currently restricted to solidcommunity.net origin) here https://github.com/elf-pavlik/mallory?tab=readme-ov-file#cuckoo

IMO current best practice is NOT to expose WebID document over Soild Protocol all together. As for discovery where to publish social profiles information, this proposed CG work item would explore that and Solid WebID Profile proposal would be one of explorations w3c-cg/solid#61 and as for any proposal we would do Threat Modeling following https://www.w3.org/TR/threat-modeling-guide/

[mrkvon]

The security risk described here is real. I don't see anybody questioning that. As other people have pointed out, it's not an argument against the Solid WebID profile specification.

I would go a step further and argue that Solid WebId Profile specification is very useful precisely in this case, when primary webid profile document is hosted outside Solid server. The specification (C2C) guides app developers in discovery and setup of other parts of the profile and other relevant data, starting from webid URI. I have found the specification very very useful in Solid app development.

If there are any outstanding issues, they can be addressed, the risks and best practices can be pointed out within the spec.

[elf-pavlik]

My main point is following. If the two requirements on the server are added as mitigation to a specific threat. We can't just drop those requirements willy-nilly. Any PR that removes those requirement should at minimum also include some form of warning about the threat that those requirements were intended to address not being adressed once again. And then the conversation IMO should focus if we want to recommend something that creates such an easy exploit.

[jeff-zucker]

how does Solid WebID proposal prevent this very clear security risk

The same way it handles OIDC, type-indexes, and SAI - by assuming that other parts of the ecosystem are working on that problem. Inrupt and many individuals have solved it by storing on non-Solid servers. NSS is experimenting with triple-level controls. Individuals have other means of protecting their profiles. It isn't up to the WebID spec to determine how a server or individual solves this issue. If we mandate one of those approaches over the other, we have eliminated the possibility of changes. By remaining neutral the WebID Profile spec can remain valid regardless of how the security issue is solved.

[elf-pavlik]

If this proposal relies on triple-level access control it should clarly state it. Otherwise with resource level access control, we simply can't rely on open wide access to the root of user's trust chain. In w3c-cg/solid#61 I imagine that we should be able to propose discovery machanism that would rely on a single statement in WebID / service in CID. It would be set by a admin level UI with 2FA etc., all the random social profile stuff managed by random (possibly insecure) apps, would hapen without messing around with user's root trust anchor.

[jeff-zucker]

I said nothing about generalized triple level access control. You still have not explained why the WebID Profile Spec should address your security concerns. If there is truly only one solution, then it should be mandated of servers in the Protocol. The WebID Profile Spec is primarily a client-to-client spec and should not be the place those concerns are addressed.

[elf-pavlik]

Once you remove those requiements on servers, which are not implemented, maybe excepts NSS experiments with triple level access control, Solid WebID Profile proposal recommends something that is clearly insecure. I don't know why you call it "your security concerns", I didn't draft this proposal.

[elf-pavlik]

If it is client - client level proposal, it should cleanly use some generic data domains discovery mechanism instead of recommending someting that renders the whole system insecure.