diff --git a/solid26.html b/solid26.html index 87efee47..cbfd1b7c 100644 --- a/solid26.html +++ b/solid26.html @@ -295,14 +295,24 @@

Table of Contents

  • 2.1 Solid Protocol
  • 2.2 Solid-OIDC
  • 2.3 Web Access Control
  • +
  • 2.4 WebID 1.0
  • +
  • 2.5 Solid WebID Profile
  • 3. Implementation Guidance

      -
    1. 3.1 WebID
    2. +
    3. +

      3.1 WebID

      +
        +
      1. 3.1.1 Requirements derivable from Solid26 Implementors Guide specifications
      2. +
      3. 3.1.2 Common assumptions not required by Solid26 Implementors Guide specifications
      4. +
      5. 3.1.3 Assembling the Profile
      6. +
      +
  • +
  • 4. Guidance for clients

  • References
  • @@ -445,6 +455,29 @@

    Web Access Control

    +
    +

    WebID 1.0

    +
    +

    WebID 1.0 (W3C Editor's Draft, 5 March 2014) is included.

    +
    +

    Note

    +

    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.

    +
    +
    +
    + +
    +

    Solid WebID Profile

    +
    +

    The Solid WebID Profile (CG Draft Report, v1.0.0, 12 May 2024) is included with the following comments:

    + +
    +
    + @@ -455,15 +488,161 @@

    Implementation Guidance

    WebID

    -
    -

    Note

    -

    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:

    +
    +
    WebID
    +
    An IRI that denotes an agent [WEBID], [SOLID-PROTOCOL].
    +
    WebID Profile Document
    +
    The Web resource obtained by dereferencing a WebID. Generally public.
    +
    Extended Profile Document
    +
    A further Web resource linked from the WebID Profile Document that contains additional statements about the WebID. Generally permissioned, but available to trusted participants (e.g. friends).
    +
    Preferences Document
    +
    A private Web resource, linked from the agent's WebID Profile, that holds settings and pointers to private data. Generally accessible only to the user (or a delegated agent).
    +
    WebID Profile
    +
    The RDF graph [RDF11-CONCEPTS] formed by the union of the WebID Profile Document with any Extended Profile Documents, assembled per § 3.1.2 Common assumptions not required by Solid26 Implementation Guide specifications.
    +
    + +
    +

    Requirements derivable from Solid26 Implementors Guide specifications

    +
    +
      +
    1. + A WebID is an HTTP URI denoting an agent (e.g. a person) [WebID 1.0 § 2 Terminology]. +
    2. +
    3. + The WebID Profile Document is the resource obtained by dereferencing the WebID HTTP URI: for a WebID with a fragment identifier (e.g. #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]. +
    4. +
    5. + A WebID Document MAY be hosted anywhere on the Web; it MAY, but need not, reside in a Solid storage [WebID 1.0 § 5 Publishing the WebID Profile Document]. +
    6. +
    7. + The WebID Profile Document MUST have a text/turtle representation [WebID 1.0 § 5 Publishing the WebID Profile Document]. +
    8. +
    9. + The WebID Profile MUST contain one or more statements of the form ?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]. +
    10. +
    11. + An agent may have zero or more Solid storages, and any number of these MAY be discoverable from the WebID Profile via statements of the form ?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]. +
    12. +
    +
    +
    + +
    +

    Common assumptions not required by Solid26 Implementation Guide specifications

    +
    +
      +
    1. + The WebID Document is a public resource (i.e. an unauthenticated HTTP GET on the WebID URI returns the Profile) [WebID 1.0 § 6 Processing the WebID Profile]. +
        +
      • The pinned specifications do not preclude a server from retrieving a non-public WebID Document via authenticated requests, but this is not well-supported in Social Web settings, where a WebID is dereferenced by many other agents' servers that cannot be assumed to make authenticated requests to WebIDs.
      • +
      +
    2. +
    3. + The 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]. +
    4. +
    5. + The WebID Profile is taken to include statements about the WebID found in the WebID Document and in any Extended Profile Document linked from it via 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: +
        +
      • An Extended Profile Document is only considered if it is self-describing for the WebID — it must contain at least one triple with the WebID as subject (i.e. ?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.
      • +
      +
    6. +
    +
    +
    + +
    +

    Assembling the Profile

    +
    + +

    Per [Solid WebID Profile § 2 Discovery], the full profile of an agent is the union of statements found in:

    +
      +
    • the WebID Profile Document;
    • +
    • any Extended Profile Documents linked from it (e.g. via rdfs:seeAlso, foaf:isPrimaryTopicOf, or owl:sameAs);
    • +
    • the agent's Preferences Document (linked via pim:preferencesFile), and any further Extended Profile Documents linked from it;
    • +
    • the agent's public and private Type Index documents (linked via solid:publicTypeIndex and solid:privateTypeIndex).
    • +
    + +

    To assemble it:

    +
      +
    1. Unauthenticated GET the WebID Document. If it is not publicly readable, surface a clear error: the WebID cannot be used for unauthenticated discovery.
    2. +
    3. For each linked document (Extended Profile Documents via 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].
    4. +
    5. Repeat step 2 transitively for Extended Profile Documents linked from the Preferences Document.
    6. +
    7. Discard any retrieved document that is not self-describing for the WebID (no triple with the WebID as subject, nor a foaf:primaryTopic triple naming it), to prevent attribution of arbitrary statements to the WebID.
    8. +
    9. Union the remaining documents with the WebID Document, dropping 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.
    10. +
    11. Drop any statement in which the WebID is neither the subject nor the object, restricting the assembled graph to statements about the agent denoted by the WebID.
    12. +
    + +
    +

    Note

    +

    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.

    +
    + +
    +
    +
    +
    +

    Guidance for clients

    +
    + +

    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:

    + +
      +
    1. +

      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.

      +
    2. +
    3. +

      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.

      +
    4. +
    5. +

      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].

      +
    6. +
    7. +

      Build the WebID Profile graph by running § 3.1.3 Assembling the Profile (do not discover storages via the solid:storageDescription Link header).

      +
    8. +
    + +
    +

    Note

    +

    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.

    +
    + +
    +

    Note

    +

    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 †):

    +
      +
    • Name: vcard:fn†, with fallbacks to foaf:name, schema:name, or rdfs:label.
    • +
    • Short name / nickname: foaf:nick†, with fallback to vcard:nickname.
    • +
    • Avatar / photo: vcard:hasPhoto†, with fallbacks to foaf:img or schema:image.
    • +
    • Email: vcard:hasEmail†, with fallbacks to foaf:mbox or schema:email.
    • +
    • Telephone: vcard:hasTelephone†.
    • +
    • Address: vcard:hasAddress†.
    • +
    • Description / bio: vcard:note†, with fallback to schema:description.
    • +
    • Birthday: vcard:bday†.
    • +
    • Organization & role: vcard:organization-name† and vcard:role†; for richer involvement, org:organization† and org:role†.
    • +
    • Pronouns: solid:preferredSubjectPronoun†, solid:preferredObjectPronoun†, solid:preferredRelativePronoun†.
    • +
    • Skills: schema:skills†.
    • +
    • Languages: schema:knowsLanguage†.
    • +
    • Friends / contacts: foaf:knows†.
    • +
    • Profile colours: solid:profileHighlightColor†, solid:profileBackgroundColor†.
    • +
    • Homepage / web page: 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.

    +
    + +
    +
    +

    References

    @@ -477,6 +656,27 @@

    References

    [WAC]
    Web Access Control. Sarven Capadisli. W3C Solid Community Group. 12 May 2024. Draft Community Group Report, Version 1.0.0. URL: https://solidproject.org/TR/2024/wac-20240512
    +
    [WEBID]
    +
    WebID 1.0. Andrei Sambra; Stéphane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/
    + +
    [WEBID-PROFILE]
    +
    Solid WebID Profile. Virginia Balseiro; Jeff Zucker; Sarven Capadisli (eds.). Tim Berners-Lee; Sarven Capadisli; Virginia Balseiro; Timea Turdean; Jeff Zucker (authors). W3C Solid Community Group. 12 May 2024. Draft Community Group Report, Version 1.0.0. URL: https://solid.github.io/webid-profile/
    + +
    [RDF11-CONCEPTS]
    +
    RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
    + +
    [FOAF]
    +
    FOAF Vocabulary Specification 0.99. Dan Brickley; Libby Miller. 14 January 2014. URL: http://xmlns.com/foaf/spec/
    + +
    [VCARD-RDF]
    +
    vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Working Group Note. URL: https://www.w3.org/TR/vcard-rdf/
    + +
    [SCHEMA-ORG]
    +
    Schema.org. W3C Schema.org Community Group. URL: https://schema.org/
    + +
    [BIO]
    +
    BIO: A vocabulary for biographical information. Ian Davis; David Galbraith. URL: https://vocab.org/bio/
    +
    [BKY+24]
    AuthApp - Portable, Reusable Solid App for GDPR-Compliant Access Granting.