diff --git a/solid26.html b/solid26.html index 87efee47..cbfd1b7c 100644 --- a/solid26.html +++ b/solid26.html @@ -295,14 +295,24 @@
WebID 1.0 (W3C Editor's Draft, 5 March 2014) is included.
+Throughout this document, references to "the WebID specification" or [WEBID] refer to WebID 1.0 as pinned here. WebID 1.0 has the status of a W3C Editor's Draft from the (now closed) W3C WebID Incubator Group; it has not progressed to a W3C Recommendation. The Solid Protocol and Solid-OIDC normatively reference WebID 1.0 for the definition of the term WebID.
+The Solid WebID Profile (CG Draft Report, v1.0.0, 12 May 2024) is included with the following comments:
+solid/webid-profile — profile-discovery-shape.ttl (discovery predicates) and profile-shapes.ttl (profile data) — can be used by implementers to validate WebID Profiles, though they are not part of the pinned specification.Work in progress: the content from the WebID guidance document is to be integrated into this section.
-This section gives implementation guidance for WebID in the context of the Solid26 Implementation Guide. It is organized into requirements derivable from the respective specifications (§ 3.1.1) and common assumptions not required by them (§ 3.1.2) (see § 2 Specifications), and a recommended profile assembly algorithm (§ 3.1.3). Guidance for client implementers is given in § 4 Guidance for clients.
+ +For the purposes of this section, the following terms are used:
+#me), the URI without the fragment denotes the Profile Document; for a WebID without a fragment, an HTTP GET on the WebID MUST return a 303 See Other response whose Location header URI denotes the Profile Document [WebID 1.0 § 2 Terminology; WebID 1.0 § 3 The WebID HTTP URI].
+ text/turtle representation [WebID 1.0 § 5 Publishing the WebID Profile Document].
+ ?webid solid:oidcIssuer ?iss, where ?webid is the WebID and each ?iss is the IRI of an OpenID Provider trusted to issue ID Tokens for that WebID [Solid-OIDC § 6.1 OIDC Issuer Discovery].
+ ?webid pim:storage ?storage, where ?webid is the WebID and each ?storage is the IRI of a storage owned by that agent [Solid Protocol § 4 Storage].
+ GET on the WebID URI returns the Profile) [WebID 1.0 § 6 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. Extended Profile Documents are themselves self-describing and may require authenticated retrieval [Solid WebID Profile § 2 Discovery; Solid WebID Profile § 3.3 Extending a Profile; WebID 1.0 § 6 Processing the WebID Profile]. Two caveats apply:
+ ?webid ?p ?o), or a foaf:primaryTopic triple naming the WebID (i.e. <> foaf:primaryTopic ?webid).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 § 2 Discovery], the full profile of an agent is the union of statements found in:
+rdfs:seeAlso, foaf:isPrimaryTopicOf, or owl:sameAs);pim:preferencesFile), and any further Extended Profile Documents linked from it;solid:publicTypeIndex and solid:privateTypeIndex).To assemble it:
+GET the WebID Document. If it is not publicly readable, surface a clear error: the WebID cannot be used for unauthenticated discovery.rdfs:seeAlso/foaf:isPrimaryTopicOf/owl:sameAs; the Preferences Document via pim:preferencesFile; Type Index documents via solid:publicTypeIndex/solid:privateTypeIndex), GET the document. Public documents may be fetched unauthenticated; on 401/403 with a logged-in user, retry authenticated. Preferences and the private Type Index will normally require authentication [Solid WebID Profile § 2 Discovery, § 4 Private Preferences].foaf:primaryTopic triple naming it), to prevent attribution of arbitrary statements to the WebID.solid:oidcIssuer from any source other than the WebID Document: it is authoritative only when sourced from the WebID Document, mirroring the write protection in Solid WebID Profile § 3.2. Other discovery predicates (e.g. pim:storage) may legitimately appear in any of these documents.The assembled WebID Profile graph can optionally be validated against profile-discovery-shape.ttl from the solid/webid-profile shapes. The shape covers pim:preferencesFile (exactly 1), pim:storage (0+), rdfs:seeAlso (0+), solid:oidcIssuer (0+), solid:publicTypeIndex/solid:privateTypeIndex (at most 1 each), and foaf:isPrimaryTopicOf (at most 1). Note that Solid-OIDC requires at least one solid:oidcIssuer in order to attest ownership of the WebID, while the shape permits zero.
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 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 § 6.1 OIDC Issuer Discovery, § 10 OpenID Provider Conformance].
Build the WebID Profile graph by running § 3.1.3 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 (see § 7 Other predicates). For empirical data on which predicates are actually populated across the ecosystem — and at what frequency — implementers should consult solid-load-profile, which loads and summarises predicate usage from a wide sample of live Solid profiles. The list below aligns with the companion profile-shapes.ttl in the solid/webid-profile shapes — which targets foaf:Person, vcard:Individual, and schema:Person — supplemented with widely-used fallbacks populated by existing profile editors (SolidOS/mashlib, Inrupt PodBrowser, PodOS, Penny). Vocabularies referenced: FOAF [FOAF], vCard [VCARD-RDF], Schema.org [SCHEMA-ORG], Org, and Solid Terms.
Common predicates for rendering a profile (predicates appearing in profile-shapes.ttl are marked †):
vcard:fn†, with fallbacks to foaf:name, schema:name, or rdfs:label.foaf:nick†, with fallback to vcard:nickname.vcard:hasPhoto†, with fallbacks to foaf:img or schema:image.vcard:hasEmail†, with fallbacks to foaf:mbox or schema:email.vcard:hasTelephone†.vcard:hasAddress†.vcard:note†, with fallback to schema:description.vcard:bday†.vcard:organization-name† and vcard:role†; for richer involvement, org:organization† and org:role†.solid:preferredSubjectPronoun†, solid:preferredObjectPronoun†, solid:preferredRelativePronoun†.schema:skills†.schema:knowsLanguage†.foaf:knows†.solid:profileHighlightColor†, solid:profileBackgroundColor†.foaf:homepage, foaf:weblog, or schema:url (not in the shape).None of these are guaranteed to be present; UIs should fall back to the WebID URI when no human-readable label is available.
+