The Solid Protocol (CG-DRAFT, v0.11.0, 2024-05-12) is included with the following comments:
Clients might encounter Servers that do not support § 5.3.1 Modifying Resources Using N3 Patches despite it being required by the Solid Protocol. Clients can use Allow headers to determine if a Server supports HTTP PATCH requests.
Clients might encounter Servers that do not support Modifying Resources Using N3 Patches despite it being required by the Solid Protocol. Clients can use Allow headers to determine if a Server supports HTTP PATCH requests.
If a server does not support HTTP PATCH requests, the client can HTTP GET the resource, apply the change locally, and then HTTP PUT the resource back. If the server supports ETag headers or Last-Modified headers, clients can achieve the concurrency-control behaviour of HTTP PATCH by issuing a conditional PUT. ETag-based validation is more precise than date-based validation and should be preferred when a server supports both, because Last-Modified has only one-second resolution and may not reflect sub-second changes.
WebID 1.0 (W3C Editor's Draft, 5 March 2014) is included.
+The Solid WebID Profile (CG Draft Report, v1.0.0, 12 May 2024) is included with the following comments:
+Work in progress: the content from the WebID guidance document is to be integrated into this section.
-This section gives WebID implementation guidance for the Solid26 Implementation Guide. It covers requirements and common assumptions drawn from the Solid26 Implementation Guide specifications, a profile assembly algorithm, and security considerations. Client-side guidance is given separately.
+ +Terms used in this section:
+pim:preferencesFile, that holds settings and pointers to private data; typically accessible only to the agent or a delegate.#me), the fragment-less URI identifies it; for a WebID without a fragment, an HTTP GET MUST return 303 See Other whose Location identifies it [WebID 1.0 § Terminology, § The WebID HTTP URI].
+ text/turtle and application/ld+json [WebID 1.0 § Publishing the WebID Profile Document; Solid WebID Profile § Reading Profile].
+ <webid> solid:oidcIssuer <iss>, where <iss> is an OpenID Provider trusted to issue ID Tokens for the WebID [Solid-OIDC § OIDC Issuer Discovery].
+ <webid> pim:storage <storage> [Solid Protocol § Storage].
+ <webid> ldp:inbox <inbox>; other agents post notifications there [Solid WebID Profile § WebID Profile Data Model; Solid Protocol § Linked Data Notifications].
+ GET on the WebID URI returns the Profile) [WebID 1.0 § Processing the WebID Profile].
+ pim:storage statement in the WebID Profile is the only sound mechanism for discovering an agent's storages. The storageDescription Link header is not to be used for this purpose: a WebID Document hosted in a storage does not imply the WebID owns that storage [Solid Protocol § Privacy Considerations].
+ rdfs:seeAlso, foaf:isPrimaryTopicOf, or owl:sameAs (collectively, discovery links) [Solid WebID Profile § Discovery; Solid WebID Profile § Extending a Profile; WebID 1.0 § Processing the WebID Profile]. Extended Profile Documents may require authenticated retrieval. One caveat applies:
+ solid:oidcIssuer is honoured only from the WebID Document; statements of the form ?webid solid:oidcIssuer ?iss in Extended Profile Documents are ignored.Per [Solid WebID Profile § Discovery], the full profile is the union of statements in:
+pim:preferencesFile) and the Extended Profile Documents it links by discovery links;solid:publicTypeIndex and solid:privateTypeIndex).To assemble it:
+GET the WebID Document. If it cannot be retrieved, surface a clear error.GET each linked document: Extended Profile Documents via discovery links, the Preferences Document via pim:preferencesFile, and Type Index documents via solid:publicTypeIndex/solid:privateTypeIndex. On 401/403 with a logged-in user, retry authenticated; Preferences and the private Type Index normally require authentication [Solid WebID Profile § Discovery, § Private Preferences]. If the WebID Document does not link a Preferences Document or Type Index documents, those fetches are skipped; their absence is not an error.solid:oidcIssuer triple that did not originate in the WebID Document: that predicate is authoritative only when sourced there, mirroring the write protection in Solid WebID Profile § Updating Profile. Other discovery predicates (e.g. pim:storage, ldp:inbox) may legitimately appear in any of these documents.When the WebID Document is not hosted in Solid storage, clients cannot add new discovery links to it. The one level of traversal from Extended Profile Documents in Solid storage lets a client attach further Extended Profile Documents (for example, at different access levels) via links it can write.
+[Solid WebID Profile § Protected properties] requires servers hosting a WebID Document to protect solid:oidcIssuer triples from modification by non-owners. Not all Solid servers implement this protection; on a server that does not, any agent with write access to the document can modify the WebID's issuer.
This section targets clients acting on behalf of a single end user — reading and writing the user's data — as opposed to authorization agents, profile editors, or server-side resource servers. The recommended flow is:
+ +Obtain the user's WebID. Prompt for a WebID URI and validate that it is a well-formed http/https URI. Surface clear errors for malformed input, 404s, and responses that cannot be parsed as RDF.
Dereference the WebID. Issue an unauthenticated GET on the WebID URI. The 303 See Other redirect to the WebID Document is expected per the "Cool URIs for the Semantic Web" pattern, but other 3xx codes (301, 302, 307, 308) may also occur and must be handled.
Authenticate the user via their OpenID Provider. Read ?webid solid:oidcIssuer ?iss from the WebID Document. If no solid:oidcIssuer statement is present, surface a clear error: the WebID is not usable for Solid authentication. If more than one issuer is listed, let the user choose. Before initiating the Solid-OIDC login flow, fetch the issuer's OpenID Connect Discovery 1.0 configuration and verify that webid appears in scopes_supported [Solid-OIDC § OIDC Issuer Discovery, § OpenID Provider Conformance].
Build the WebID Profile graph by running Assembling the Profile (do not discover storages via the solid:storageDescription Link header).
pim:storage may yield more than one value. When the application needs exactly one storage to write data into, prompt the user to choose rather than picking one silently.
The Solid WebID Profile [WEBID-PROFILE] does not standardise predicates for rendering an agent's identity. For empirical data on which predicates are actually populated across the ecosystem, implementers can consult solid-load-profile, which summarises predicate usage from a sample of live Solid profiles. The list below targets foaf:Person, vcard:Individual, and schema:Person, drawing from the predicates read by existing profile renderers including SolidOS/mashlib, PodOS, Penny, and dokieli. Vocabularies referenced: FOAF [FOAF], vCard [VCARD-RDF], Schema.org [SCHEMA-ORG], ActivityStreams, SIOC, Org, and Solid Terms.
The following is a list of fallback predicates that applications may wish to consider using when rendering a profile. The order given for each field is a suggested preference; other orderings may be more appropriate depending on the ecosystem the application integrates with.
+foaf:name, with fallbacks to schema:name, vcard:fn, as:name, or rdfs:label. For structured names: schema:givenName+schema:familyName, foaf:givenName+foaf:familyName, or vcard:given-name+vcard:family-name.foaf:nick, with fallback to vcard:nickname.vcard:hasPhoto, with fallbacks to as:image, as:icon, foaf:img, schema:image, vcard:photo, sioc:avatar, or foaf:depiction.vcard:hasEmail, with fallbacks to schema:email or foaf:mbox.vcard:hasTelephone.vcard:hasAddress (with vcard:country-name, vcard:locality on the value).vcard:note, with fallback to schema:description.vcard:bday.vcard:organization-name and vcard:role; for richer involvement, org:organization/org:member and org:role, or schema:hasOccupation.solid:preferredSubjectPronoun, solid:preferredObjectPronoun, solid:preferredRelativePronoun.schema:skills, with fallback to cco:skill.vcard:language, with fallbacks to schema:knowsLanguage or solid:preferredLanguage.foaf:knows, with fallback to schema:knows.solid:profileHighlightColor, solid:profileBackgroundColor.foaf:homepage, foaf:weblog, schema:url, or vcard:url.foaf:account, with account nodes carrying foaf:accountName and foaf:userProfilePrefix.None of these are guaranteed to be present; UIs should fall back to the WebID URI when no human-readable label is available.
+Data discovery beyond the profile varies across the ecosystem. Mechanisms in active use include: Type Indexes; Solid Application Interoperability (SAI); SPARQL or Quad Pattern Fragments endpoints; fixed paths under the root of a storage; and DCAT catalogues. This guide does not prescribe a single mechanism.
+