Proposed Conformance Model

[jeff-zucker]

[EDIT - updated based on Editor's meeting of 2022-09-06, but not including all the comments since last update. This model is likely to change]

Given that IdPs may wish to restrict how WebID Documents behave, including limiting the ability of the WebID owner to write to the document, we need to support the ESS-like model in which the WebID document is not the same document as the Profile document.

If we proceed as I've outlined below, we would have two shapes which can occur in one document or in two documents. In the NSS-like instance where the same document is both the WebID document and the Profile document, it would need to conform to both shapes. In the ESS-like instance the WebID Document could be very minimal and the Solid Profile Document would conform to the same shape as all other Solid Profile Documents.

I also propose a solid:profileDocument predicate. We can add a note that, for backward compatibility, developers may wish to also check for the foaf:primaryTopicOf predicate.

Solid Profile Data Model Conformance

The Solid WebID Document

This document should follow the rules set forth in the WebID Specification including (TBD:get exact wording)

And it should follow this rule, introduced by this spec

• it MUST either conform to the rules listed below for a Solid Profile Document or else have a triple equivalent to <?WebID> solid:profileDocument <?SolidProfileDocument>.. For backward compatibility, the predicate can be foaf:primaryTopicOf instead.

In order to be usable for purposes of verifying identity, a WebID document should also contain predicates mandated by the identity protocol in use. For example if the Solid-OIDC protocol is in use, the WebID document MUST include a triple equavent to <?WebID> solid:oidcIssuer <?Issuer>. See the Solid-OIDC specification for details

The Solid Profile Document

• there MUST be exactly one Solid Profile Document for any given WebID URI
• it MUST have exactly one space:preferencesFile triple
• it MUST be writable by the WebID owner or those they designate
• it SHOULD have exactly one ldp:inbox triple
• it SHOULD have one or more space:storage triples
• it MAY have zero or more triples with the solid:community predicate
• it MAY have zero or more triples with the rdfs:seeAlso predicate
• it can be the same document as the WebID Document or it can be a separate Document. In the case in which the Solid Profile Document and the Solid WebID Document are the same, the document MUST conform to the rules listed above for both types of documents.

The Preferences Document (space:preferencesFile)

• there MUST be exactly one Preferences Document
• it MUST be writable by the WebID owner or those they designate
• it MUST NOT be readable or writable by anyone other than the WebID owner or those they designate
• it MAY have zero or more triples with the rdfs:seeAlso predicate

Extended Profile Documents (rdfs:seeAlso)

• there MAY be zero of more extended profile documents
• they MAY be accessible to public, restricted, or private audiences

Note: Apps can be expected to examine triples in seeAlso documents with the WebID as subject. They are free to but not required to examine other triples.

Note: Apps are free to but are not required to examine triples in seeAlso documents using the rdfs:seeAlso predicate.

[VirginiaBalseiro]

I will try my best to summarize my views without repeating stuff already said above.

I agree with Ruben that this spec should not revolve around how access control is applied to any resources.

I also see, as an app developer, the difficulty in designing UIs that feel familiar to both users and developers, and the need to make this more predictable for developers.

I do however think that since Solid imposes a different paradigm, we should strive to make this transition easier, but still setting the correct expectations.

The way I see the Solid ecosystem in a future is, servers (and therefore different providers, identity providers, Pod providers, and so on) will offer different features and users will prefer one or the other or many based on their own preferences. This ties into the idea of the user having choice over what to do with their online identity and personal data.

Apps should be prepared for a scenario where a WebID document is not editable and contains no links to any profile document. Would the app be unusable? In some cases, yes. Depending on the user case, it will likely be limited in what it can do unless the user contacts their provider and voices their concern, or changes provider. The audience of this spec is app developers, not server implementers.

What I am saying is that I think this document should not make limiting requirements such as there must be exactly one profile… or the profile must be private/public... I think we need to describe what the possibilities are, and recommend a reasonable course of action.

To take the above question by Jeff as an example, what should an app do if there is a huge number of profiles, should it follow all… I would recommend always asking the user (and this applies to multiple anything, like multiple Pods). “We found X amount of profiles, pick one for this thing you are trying to do/using this app”. There are examples of this, just speaking from the user interaction perspective, one being Google profiles.

So all in all, it’s not that I don’t see the advantage in trying to set a limit to these things, it is more that I don’t think it is this spec’s responsibility to do so, and I also think it might be better to focus our efforts on trying to reach a set of reasonable best practices around designing UIs. This is a big challenge because of the paradigm shift, so I believe the more resources we have tackling this topic (such as this spec), the better.

So I would say: you can expect that either the WebID document is editable, or it contains a link to an extended profile document, or many. Prefer those which are a solid:ProfileDocument (or linked through solid:profileDocument), but understand that there might be others, and weigh the pros and cons of fetching them all depending on your app’s needs. Be prepared for the case where neither is true, and you can only work with a WebID and take it into account when handling errors in your application.

[jeff-zucker]

@VirginiaBalseiro wrote

Apps should be prepared for a scenario where a WebID document is not editable and contains no links to any profile document.

I agree. Our spec can't force anything about the WebID document. I retract anything I've said so far that implies that we should.

I would recommend always asking the user (and this applies to multiple anything, like multiple Pods)

A profile isn't necessarily used by the owner so what would a visiting app run by someone other than owner do? What would be offered to them to choose from? What about bot apps that just want to read or write something? Who would be asked to choose?

you can expect that either the WebID document is editable, or it contains a link to an extended profile document, or many

Is the app responsible for opening extended profile documents inside extended profile documents? If so, when does that stop?

If the WebID document is not editable by the Solid Protocol (which is its right), and there can be many extended profile documents, but no single Solid Protocol addressable location to point to them, how does an app create a link to one of these extended profile documents other than by creating a link to an extended profile document inside another extended profile document?

[jeff-zucker]

@VirginiaBalseiro wrote :

I agree with Ruben that this spec should not revolve around how access control is applied to any resources.

I agree with that also. The recommendations I would like to see are about if access controls are applied, not how. There are really only two questions my recommendation deals with and neither depends on how permissions are handled or restricts users ability to handle differing consents.

should the information be accessible to anyone other than the profile owner?                                       
  yes ->  should the information be available to all users and all apps visiting this profile?                                                         
    yes : profile document                                                                                                                            
    no  : extended document pointed to from the profile document                                                                                      
  no -> should the information be available to all apps visiting this profile when profile owner is user?                                                                       
    yes : preferences file                                                                                                                            
    no  : extended document pointed to from the preferences file                                                                                      

[EDITED for clarity]

[jeff-zucker]

@VirginiaBalseiro wrote

this document should not make limiting requirements such as ... the profile must be private/public

I will now agree with this point. The profile document could be private/pubic/restricted as owner wants. There would hopefully be UIs to easily convert the permissions.

[jeff-zucker]

you can expect that ... the WebID document is editable

No, you can't, but a WebID document and a Solid Profile Document are not the same thing. You should, I believe, be able to expect that a Solid Profile Document is editable by the WebID owner using a Solid software of their own choosing. The idea that the owner would need to contact the Identify Provider in order to edit their own profile makes the idea of ownership meaningless. So if the WebID Document is not editable using Solid software, it is free to not point to a Profile Document or anything else it wants. But if it wants apps to interoperably connect to a Solid Profile, it needs, in my opinion, to point to a document or documents the WebID owner can edit using the Solid protocol.

[jeff-zucker]

^^ For example, it seems to me to be completely against the Solid philosophy that the Identity Provider, without my consent, makes my storages visible to the world and does not allow Solid apps I choose to add, remove, or change the visibility of storages. Those things, to me mean I do not own my own profile.

[NoelDeMartin]

Thanks @jeff, I opened a follow up about the caching in https://github.com/solid/webid-profile/issues/47

[@angelo-v] What is the point in having a public profile, that does not contain any public data?

[@RubenVerborgh] the whole design is starting to be based on a permissions model, whereas permissions are supposed to be orthogonal in Solid.

[@VirginiaBalseiro] I agree with Ruben that this spec should not revolve around how access control is applied to any resources.

Although I agree with the general idea that permissions shouldn't be tackled heavily in this spec, I still think it's important to set clear guidelines for what apps can expect from a WebID.

In particular, I want to at least know whether a url is a WebID or a random url from the internet. If a WebID is not publicly-readable and I get an error response, I don't know if that's because the WebID is private or it just isn't a WebID.

This concern arises from the UX difficulty we discussed in the forum. TLDR: I can't be sure if what users introduce when logging in is a WebID or an issue provider url or what. So in my apps, I try to search for a valid WebID and get the issue provider from there. If I can't, I just use whatever they typed as the issue provider.

Having that into account, I think it's useful that WebIDs are public even if the only public information is that they are indeed a WebID and what issue provider to use.

[@VirginiaBalseiro] To take the above question by Jeff as an example, what should an app do if there is a huge number of profiles, should it follow all… I would recommend always asking the user (and this applies to multiple anything, like multiple Pods). “We found X amount of profiles, pick one for this thing you are trying to do/using this app”

As I'm understanding this spec, all profile documents are conceptually part of the same profile, they are just separated in order to have different permissions, reduce the number of requests, or any other reasons.

So the idea of querying all documents or not is just an implementation detail to improve performance, but I don't think it's a problem a user should be concerned about.

[jeff-zucker]

I still think it's important to set clear guidelines for what apps can expect from a WebID. In particular, I want to at least know whether a url is a WebID or a random url from the internet.

The WebID Document is defined in the WebID spec which says in a non-normative section "A WebID Profile is a public document". The Solid-OIDC spec raises that as an issue but does not definitively say that a Solid-OIDC compliant WebID Document must be public. If you are interested in ensuring a public WebID document you should contribute to that spec : https://solidproject.org/TR/oidc#oidc-issuer-discovery or to the WebID spec.

So the question of whether the WebID Document is public will not be decided in this current spec. What we will have to decide on is whether, when the WebID Document is different from the Solid Profile Document and only points to that document whether that pointed to document, the Solid Profile Document, is public. The consensus seems to be that we should not specify that.

[jeff-zucker]

@NoelDeMartin here are the definitions I would like to use :

From the WebID Specification : "A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, Device, etc.)."

From the WebID Specification : "A WebID Profile Document is an RDF document which uniquely describes the Agent denoted by the WebID in relation to that WebID."

Proposed by me : "A Solid Profile is a set of WebID Profile Documents that are readable and writable using methods described in Solid Protocol. The starting point of the Profile can be dereferenced directly from the WebID URI if that document is accessible via the Solid Protocol, or can be indirectly dereferenced by finding a solid:profileDocument triple in the document the WebID URI dereferences to."

Adapted by me from Solid Protocol - "A WebID owner is a person or a social entity that is considered to have the rights and responsibilities of a WebID and its associated Solid Profile. An owner is identified by a URI, and implicitly has control over all data in the Solid Profile associated with that URI."

[timea-solid]

This discussion clearly shows the hard line the editors need to walk between What is possible now with the Solid Profile and What we want the Solid Profile to be in the future. Initially, we set out to write down how it is right now so that dev have an easier time just focusing on what they love: code.

As a result, we should take a step back and leave some things as they are -> meaning: link to the location in the other specs where you find more information. For example link to: "The Solid-OIDC spec raises that as an issue but does not definitively say that a Solid-OIDC compliant WebID Document must be public." This is something we already realized we need to do in more places of this spec. We can take this discussion point in the weekly meetings because it touches on the goal of the spec.

As for the topic itself: my wish is to have in the future a so-called triple level privacy control, case in which you can have only one Solid Profile that can have all info and control the user wants/needs. The 'possibility' should stay open after this spec. (As an example: we decoupled type indexes from WebID to make sure we don't stop progress on Solid indexes.)

[jeff-zucker]

@timea-solid - I agree that we should, as much as possible, depend on existing specs and not duplicate their work. We should talk about the WebID Profile Document and OIDC non-normatively as part of the discovery process but not make any normative statements about them.

I also agree that the future is permissioned triples and that our spec absolutely should not do anything that would impede the development or deployment of permissioned triples or other future developments. OTOH, when permissioned triples are available, this spec will need to be changed. We can't possibly write a spec for permissioned triples now. And when will permissioned triples be available? (one year? five years?). I think it would be a disaster to have no profile spec between now and then. Is document permission messy and should be replaced ? Yes, definitely. Is it what we have to work with today? Yes.

To me the most important parts about the profile are

1) the Solid Profile should be modifiable by solid apps of the user's choosing and totally under the WebID owner's control (see my proposed definitions) . The Identity Provider is welcome to maintain control over the document the WebID URI dereferences to for their own purposes (such as oidcIssuer) when it is located on their own servers rather than on a Resource Server, but it can not claim that that document is a Solid Profile. It isn't, it points to a Solid Profile. Otherwise apps can not modify profiles and apps are the point in the ecosystem that need to modify profiles. Today we have a server putting our storages in public view without our permission, what is to stop a server from putting our name and passport number in the WebID document and make us make requests to them to change it? If servers rather than apps determine the shape of profiles and we can't aim a specification at servers to control that process, that means profiles are irrevocably living in the wild west where each Identity Provider gets to decide what a Solid Profile looks like. In my opinion, the server is free to add other features, but it can not do so by interfering with a user's ownership of their own profile and all of the data in it.

2) There should be a clear way for users and app developers to know where to put and look for differently permissioned materials. It should, as much as possible, support existing practice. SolidOS and many other apps are designed to work within the document permissioning system as outlined in my proposal which is itself based on the previous attempt at the webid-profile specification which was all apps have had to go by until now. I am not in favor of telling all of those apps, oh forget about that, just put stuff where you want to. I won't repeat myself on this, I think this sums up my view on permissioning.

3) The profile should, as much as possible, be designed to minimize document loads.

[jeff-zucker]

@timea-solid - in response to your mention of triple-level permissioning, I said "We can't possibly write a spec for permissioned triples now." but I now believe I am wrong about that. We can say an app writing or repairing a profile on a server that supports triple-level permissioning should, when possible put all triples directly in the Solid Profile Document but may, if it wishes, follow the document model we propose. Apps on servers that only support document level permissioning should follow the recommendations we propose for writing documents. Apps reading a profile on either type of server should read the Solid Profile Document and if that doesn't tell them what they need to know, follow the document recommendations we make to load and query. That seems to me to make our spec work with either kind of permissioning.

[jeff-zucker]

I believe Trinpod has already implemented triple-level permissioning. @gibsonf1 would the paragraph above this work for you?

[csarven]

re Editor Role:

The editor is expected to apply the consensus decisions of the Group. The editor is not expected to have all the responsibilities of the author or rights to matters which the Group does not explicitly decide. In practise, there is leeway. Editors need to practise egoless writing and they can be influential voices in Group deliberations.

(I'll look into adding something along these lines to CONTRIBUTING.md.)

---

re Orthogonality:

It is expected that specifications are kept orthogonal ( https://www.w3.org/TR/webarch/#orthogonal-specs ) and overlapping features are clearly indicated: https://solidproject.org/TR/protocol#introduction .

The WebID Profile specification is deemed to focus on identity - attached data towards presenting an agent in different contexts - and discovery, without venturing too far into identification, authentication, authorization, or modifying abstractions described elsewhere.

---

re Profile

https://gitter.im/solid/webid-profile?at=6310b75fd020d223d3181b8f :

Clarify how a profile is a presentation of an agent. whether an agent can have different profiles and what their relationships may be.. "Extended profile" is a bit of plumbing (but essentially about the same identity). It is an answer for the need to distribute information into different resources for different reasons, access privileges being one.

To define:

• https://solid.github.io/webid-profile/#solid-profile
• https://solid.github.io/webid-profile/#extended-profile

To introduce, reuse, and clarify relationship:

re "owner", GOTO https://github.com/solid/webid-profile/issues/40#issuecomment-1231860197

re "agent": The SOLID-PROTOCOL defines "agent" https://solidproject.org/TR/protocol#agent as:

An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [WEBID].

---

re Authentication

Clarify the abstractions involving "Identity Provider".

Consider the following for a moment: if it is deemed that a WebID Profile Document may not necessarily be a resource available from a Solid server, could the same kind of assumption not be made about a "provider" (or even Solid-OIDC in particular)? 5+ years ago we would a similar consideration could've been made when WebID-TLS was the focus for authentication.

---

re WebID Profile Document Access Privileges:

The intended access privileges about WebID Profile Documents is clarified in https://github.com/w3c/WebID/pull/7 ( as per https://github.com/w3c/WebID/issues/1 ) in that the WebID 1.0 specification does not set a constraint - documents can be public or protected, and they may contain public or private information.

[jeff-zucker]

re Editor Role:

The editor is expected to apply the consensus decisions of the Group.

Not sure why you're mentioning that here, but I've tried to speak only for myself and have clarified that several times in the discussion. The top posting will try to reflect the group consensus, not my opinion and other Editors are free to edit it.

re Orthogonality:

I agree entirely. We should not redefine anything in the WebID or Solid-OIDC and should conform to previous specs except in the few case where we are introducing something new.

The WebID Profile specification is deemed to focus on identity - attached data towards presenting an agent in different contexts - and discovery, without venturing too far into identification, authentication, authorization, or modifying abstractions described elsewhere.

Yes, agree, this spec should focus on presentation of identity and on discovery, and refer to other specs for identification, authentication, and authorization.

Clarify how a profile is a presentation of an agent. whether an agent can have different profiles and what their relationships may be..

Absolutely. This is a very important step, I agree. I already have a number of use case scenarios but there should also be an overview.

To define:

• https://solid.github.io/webid-profile/#solid-profile
• https://solid.github.io/webid-profile/#extended-profile

Yes.

To introduce, reuse, and clarify relationship:

re "owner", GOTO #40 (comment)

re "agent":

Yes point to Protocol and WebID for this.

re Authentication

Clarify the abstractions involving "Identity Provider".

I think we can skip much mention of them. But yes, if we use the term we should define it.

re WebID Profile Document Access Privileges:

The intended access privileges about WebID Profile Documents is clarified in w3c/WebID#7 ( as per w3c/WebID#1 ) in that the WebID 1.0 specification does not set a constraint - documents can be public or protected, and they may contain public or private information.

Agree, we should not place requirements on the permissions on a WebID/Solid Profile Document.

[elf-pavlik]

it SHOULD have one or more space:storage triples

I raised specific a issue about space:storage #51

I see it similar to solid:oidcIssuer conversation which led to:

@elf-pavlik - or perhaps you are right that it does not belong here at all. If it is removed, then the dependency tree would go WebID Spec <- Solid Profile Spec <- OIDC/InterOp/Index/New Specs. So my current thinking is remove solid:oidcIssuer, point to the WebID Spec for all conformance rules except the solid:profileDocument predicate. Explain in non-normative text that Solid-OIDC is the currently most widely used identity protocol and that therefore the solid:oidcIssuer can be expected in the WebID document.

Solid Application Interoperability does NOT use space:storage at all. Instead, as I explain in #51 it defines two distinct paths. One for Authorization Agent and the second for other Applications (TL;DR go to Authorization Agent so that the user can authorize your access first, since even the discovery is limited to just what that app access).

I think that whatever (mini)spec relies on space:storage for discovery, and however it takes authorization into account (if at all), it should extend Solid Profile Spec in the same way SAI will be extending it.

If more than one discovery specs rely on that predicate, it might be justified to propose it up the spec chain, I don't think this is the case for space:storage.

---

I believe this Other Predicates should be a separate living document which can be amended as different specifications develop. It would have a list of predicates used in the WebID document and Profile document. This would be a lightweight version of something like IANA Link Relations registry https://www.iana.org/assignments/link-relations/link-relations.xhtml

I still think this would be the cleanest approach for documenting what can be expected in Solid Profiles without adding:

it SHOULD have one or more space:storage triples

Just to potentially realize a year or two later that SHOULD NOT would have been more appropriate.

[jeff-zucker]

I believe this Other Predicates should be a separate living document which can be amended as different specifications develop. It would have a list of predicates used in the WebID document and Profile document. This would be a lightweight version of something like IANA Link Relations registry https://www.iana.org/assignments/link-relations/link-relations.xhtml

An interesting idea, we'll discuss.

it SHOULD have one or more space:storage triples

That statement will not occur in isolation, rather will occur in the context of a description of why a person might or might not want their storage(s) findable.

[jeff-zucker]

Closing this issue. It should have been a discussion rather than an issue. Many of the points here have been taken up in other issues and there is no particular proposal in this issue which needs to be acted on. However, useful discussion for historical purposes.

[timbl]

If you close this as the points have been taken up in other issues, please link to this issues.

[jeff-zucker]

@timbl - My understanding is that @VirginiaBalseiro is working on a new set of conformance rules (see https://github.com/solid/webid-profile/issues/89) and I did not feel it would be helpful to bring up issues until those are available for review. That way we can start from a review of what she proposes rather than with this issue which became muddled. If her conformance rules don't address my concerns, I will certainly raise the issues again.