solid26: WebID Guidance by jeswr · Pull Request #781 · solid/specification

jeswr · 2026-04-19T14:39:05Z

This PR adds the WebID 1.0 and the Solid WebID Profile to Solid26.

Additionally it provides:

Guidance on what can be concluded from all input documents to Solid26 as far as WebID's are concerned
Clear algorithms on how to construct a Solid WebID profile. I have intentionally been more prescriptive than the existing specification here so that implementors have clear guidance. I would very much appreciate a review from the authors of the Solid WebID profile document, and I am happy to contribute this to the Solid WebID profile spec.
A guide for "common clients" on how to authenticate a user, and construct their user profile

A preview link can be found here.

cc @uvdsl @csarven @jeff-zucker @VirginiaBalseiro @timea-solid

jeff-zucker · 2026-04-19T14:41:29Z

Great! Thanks. Minor quible: 404 on the link to "here".

…

On Sun, Apr 19, 2026 at 7:39 AM Jesse Wright ***@***.***> wrote: This PR adds the WebID 1.0 and the Solid WebID Profile to Solid26. Additionally it provides: - Guidance on what can be concluded from all input documents to Solid26 as far as WebID's are concerned - Clear algorithms on how to construct a Solid WebID profile. I have intentionally been *more* prescriptive than the existing specification here so that implementors have clear guidance. I would very much appreciate a review from the authors of the Solid WebID profile document, and I am happy to contribute this to the Solid WebID profile spec. - A guide for "common clients" on who to authenticate a user, and construct their user profile A preview link can be found here <https://htmlpreview.github.io/?https://github.com/solid/specification/blob/solid26-webid/solid26.html> . cc @uvdsl <https://github.com/uvdsl> @csarven <https://github.com/csarven> @jeff-zucker <https://github.com/jeff-zucker> @VirginiaBalseiro <https://github.com/VirginiaBalseiro> @timea-solid <https://github.com/timea-solid> ------------------------------ You can view, comment on, or merge this pull request online at: #781 <#781?email_source=notifications&email_token=AKVJCJARRQ2FLZZENRQO7434WTQKBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTKNJSGE4DCOBVGCTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K24DSL5XXAZLOL5RWY2LDNM> Commit Summary - 0e5cf2c <0e5cf2c?email_source=notifications&email_token=AKVJCJG5BR5EIXD2326UAZT4WTQKBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTKNJSGE4DCOBVGCTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K64DSL5RW63LNNF2F6Y3MNFRWW> feat: boostrap webid section - 8d3dbe4 <8d3dbe4?email_source=notifications&email_token=AKVJCJG5BR5EIXD2326UAZT4WTQKBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTKNJSGE4DCOBVGCTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K64DSL5RW63LNNF2F6Y3MNFRWW> feat: enhance Solid26 guidance sections File Changes (1 file <https://github.com/solid/specification/pull/781/files?email_source=notifications&email_token=AKVJCJFPVWNSGPWGMGPMUSL4WTQKBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTKNJSGE4DCOBVGCTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K44DSL5TGS3DFONPWG3DJMNVQ> ) - *M* solid26.html <https://github.com/solid/specification/pull/781/files?email_source=notifications&email_token=AKVJCJGGVLWSZDB6MKWAQW34WTQKBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTKNJSGE4DCOBVGCTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K24DSL5TGS3DFL5RWY2LDNM#diff-e25c223e19f18bbcf46b73537d402acc9646640a8623a8e2756ac78755883dc2> (212) Patch Links: - https://github.com/solid/specification/pull/781.patch <#781.patch?email_source=notifications&email_token=AKVJCJB43AHOFTV3HVSHRTD4WTQKBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTKNJSGE4DCOBVGCTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K44DSL5YGC5DDNBPWG3DJMNVQ> - https://github.com/solid/specification/pull/781.diff <#781.diff?email_source=notifications&email_token=AKVJCJCDB3W7FQXEHBRJFG34WTQKBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTKNJSGE4DCOBVGCTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2K24DSL5SGSZTGL5RWY2LDNM> — Reply to this email directly, view it on GitHub <#781?email_source=notifications&email_token=AKVJCJHFLZG3Y2COUZS53AT4WTQKBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF4ZTKNJSGE4DCOBVGCTHEZLBONXW5J3NMVXHI2LPN2SWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKVJCJGKO765JNSIEZFCI5T4WTQKBAVCNFSM6AAAAACX6SQ6EOVHI2DSMVQWIX3LMV43ASLTON2WKOZUGI4TCMJUG44TKMY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

jeswr · 2026-04-19T15:03:45Z

Link fixed @jeff-zucker - thanks for catching!

… and refined predicate listings

…predicate usage

…ID Profile

csarven

Thanks for kicking this off. Though I don't understand why this is not carried out in the main solid26 PR. I've only looked through the WebID related parts in this PR, and don't necessary dis/agree or endorse whatever else is included in this document.

Indicating section numbers of referenced material is not particularly reliable generally. For snapshots, the numbers may be reliable but it still reads a bit odd e.g., "§ 3.2". Could leave them out IMO or they should always be used consistently in the whole document.

Left inline comments.

elf-pavlik · 2026-04-19T19:38:13Z

If Solid26 guide includes Solid WebID Profile and CG Type Indexes (LWS WG has more privacy aware version), I think it should also mention known security & privacy issues with both of those proposals. I can PR them once we agree where exactly they should go.

jeswr · 2026-04-19T21:14:27Z

Thanks for kicking this off.

Thanks for the review(s)!

Though I don't understand why this is not carried out in the main solid26 PR. I've only looked through the WebID related parts in this PR, and don't necessary dis/agree or endorse whatever else is included in this document.

There is quite a lot of discussion on the other PR. I opened this up separately so that I can easily see and action comments specifically on the WebID without it getting lost amongst all the existing comments on the main PR.

Once I have incorporated most of the feedback from the Solid WebID Profile authors I plan to merge this into the solid26 branch.

Indicating section numbers of referenced material is not particularly reliable generally. For snapshots, the numbers may be reliable but it still reads a bit odd e.g., "§ 3.2". Could leave them out IMO or they should always be used consistently in the whole document.

Thanks for the steer. Happy to drop section numbers!

uvdsl

This is part 1 of my review on this.

Co-authored-by: Christoph Braun <braun@kit.edu>

… to WebID)

elf-pavlik · 2026-04-22T17:17:20Z

@jeswr you wanted my comments on Security and Privacy captured somewhere besides minutes, In short

Security of `solid:oidcIssuer`

Demo of very simple exploit: https://github.com/elf-pavlik/mallory#cuckoo
Section suggesting that this may be mitigated but with 0 implementations https://solid.github.io/webid-profile/#protected-properties

Privacy for Type Indexes

WG darft includes https://pr-preview.s3.amazonaws.com/w3c/lws-protocol/pull/115.html#security-and-authorization
CG draft discloses existance of types even if requesting credentials don't allow access to those resources.

jeff-zucker · 2026-04-22T18:13:02Z

The security of the issuer triple is an important issue, but it is the responsibility of the server not the client. There is nothing a client needs to or can do to change that. If my app writes a seeAlso triple in the document, that does nothing at all to impact the security of the document. So what exactly is the advice to clients here? Don't use servers that expose the issuer?

The exposure of the type index is a red herring. There is nothing in the draft that says an app MUST place pointers to its data in a type-index. So a caveat in the text might be something like "If you do not want to expose the types used by your app, don't put them in the type index". What would be the point of having them in the type index if no other app is supposed to see them?

elf-pavlik · 2026-04-22T18:27:02Z

So what exactly is the advice to clients here? Don't use servers that expose the issuer?
[...]
"If you do not want to expose the types used by your app, don't put them in the type index".

I don't see Soild 26 being published just for app developers, but even if someone develops an app that works with sensitive data, it could warn user about their WebID not being protected from identity high-jacking / impersonation and asking to use a different WebID or move their WebID to a secure provider.

And yes, if someone develops app where wide disclosure of specific types existence in user's storage is undesired. They shouldn't add those types until the issue is addressed, for example by work happening in LWS WG.

Those considerations are useful more broadly, especially for anyone who needs to meet certain security and privacy requirements. If we have specific well known issues, I would prefer to disclose them up front, rather than let someone invest weeks or months into some work just to realize that those issues exist and are a show stopper for them.

Co-authored-by: Christoph Braun <christoph.braun@protonmail.com>

Use "HTTP URI" for the WebID definition to match the normative section. Drop "Web resource" (not an established term) and the "Generally public / permissioned" hedging; state the auth property precisely where it matters.

Replace "transitively from the Preferences Document" recursion with an explicit, bounded traversal: one level from Extended Profile Documents linked directly off the WebID Document; no further traversal from Preferences-linked or Type-Index-linked documents. Introduce "discovery links" as a shorthand for rdfs:seeAlso / foaf:isPrimaryTopicOf / owl:sameAs and reuse it throughout §3.1.2 and §3.1.3. Add a note explaining why one level of traversal is needed when the WebID Document is not itself in Solid storage.

Visibility of the WebID Document is covered in §3.1.2. Step 1 only needs to surface an error when retrieval fails.

…Solid storage Address the case where the WebID Document itself cannot be modified by Solid clients: advise linking an Extended Profile Document in a Solid storage so clients have a writable attachment point for profile statements.

…cument Align with Solid WebID Profile §3.1 Reading Profile, which extends WebID 1.0's Turtle-only requirement to include JSON-LD.

PodBrowser is no longer actively maintained; dokieli is a widely-used reader/writer of agent profiles.

Make the reader/writer contract explicit: readers should accept any of the listed predicates as equivalent for a given field; writers typically commit to one. The stated order is a suggested preference and may vary by the ecosystem an application integrates with.

[BIO] was listed in §References but never cited in the document.

A WebID without an oidcIssuer cannot authenticate via Solid-OIDC; clients should tell the user rather than failing opaquely further into the login flow.

Not all WebIDs link a Preferences Document or Type Index documents; clients should skip their fetch silently rather than fail.

…ment filter The earlier document-level 'self-describing' filter was a solid26-specific precaution not present in Solid WebID Profile. The current spec (§2 Discovery) states the profile is assembled by collecting statements with the WebID as subject or object. Drop the document-level filter; keep the statement-level filter and reword step 6 positively to match the spec. Also collapses §3.1.2 from two caveats to one (solid:oidcIssuer origin) and removes the now-obsolete step 4 in §3.1.3 — which means the 'switch steps 3 and 4' and 'explain step 4 better' colleague asks dissolve naturally.

Client-side data discovery varies across the ecosystem; list the common mechanisms (Type Indexes, SAI, SPARQL / Quad Pattern Fragments endpoints, fixed paths under storage root, DCAT) without prescribing one.

Solid WebID Profile §Protected properties requires servers to protect solid:oidcIssuer triples, but no known Solid server implements this at time of publication; flag the implication for implementers in an informational subsection.

Drop the shape-validation note in §3.1.3, the profile-shapes.ttl reference and dagger markers in §4, and the companion 'not in the shape' annotation. Shape documentation belongs in the WebID Profile repo, not in this implementation guide.

Drop the SHOULD-accept-as-equivalent normative framing; present the list as optional fallbacks applications may consider.

Derive the fallback ordering from what dokieli and SolidOS profile-pane actually read: flip Name to foaf:name-first, broaden Avatar to the full dokieli chain, add social accounts, schema:hasOccupation, cco:skill, vcard:language, solid:preferredLanguage, schema:knows, vcard:url. Pull ActivityStreams and SIOC into the referenced vocabularies.

Per csarven (PR #781) and jeswr's agreement: section numbers in referenced specs are not reliable across snapshots. Keep link text as the section title only; internal cross-references within this document keep their numbers.

Remove duplicated and filler phrasing across §3.1: - Intro lists subsections (incl. new §3.1.4) without restating them. - Term-dl header: 'For the purposes of this section' dropped. - Fix 'Implementors Guide' typo in §3.1.1 heading. - Compact '?webid ?p ?o, where ?webid is the WebID and each ?iss is…' patterns to one statement-form with inline angle-bracket terms. - Drop '(e.g. a person)' filler. - Collapse 'MAY be hosted anywhere; it MAY, but need not, reside…' to single clause. - Tighten the Profile Document URI-resolution sentence, and several notes / algorithm steps that repeated 'Extended Profile Document' / 'Solid WebID Profile' within the same sentence.

Use 'Not all Solid servers implement this protection' rather than 'No known Solid server', and restore the fuller wording about Preferences/Type Index documents being absent.

Inline section names as link text instead of '§ 3.1.1' / '§ 3.1.3' style refs; reads naturally without relying on the TOC numbering. Both 'set union' occurrences now read 'set union of statements' to make the RDF-graph semantics explicit.

Per csarven: framing certain specs as 'pinned' reads as gatekeeping and adds no value for the reader. Rephrase the §3.1 intro so requirements and common assumptions are stated as drawn from the Solid26 Implementation Guide specifications, and trim the §3.1.2 sub-bullet to 'These specifications do not preclude...'.

jeswr · 2026-04-24T01:02:27Z

On the security/privacy concerns raised by @elf-pavlik:

solid:oidcIssuer protection. Added a new §3.1.4 Security Considerations in 1a8508c (later softened in 656d603). It reads:

[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.
Type-index disclosure. The broader point about data-discovery mechanisms (including Type Indexes, SAI, the LWS PR, and others) is noted in be009c2 at the end of §4:

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.

Happy to refine the wording or expand the type-index privacy framing if this doesn't capture what you had in mind.

The assembly algorithm unions statements from the Preferences Document and Type Index documents as well as Extended Profile Documents; the term definition now names all four sources.

jeswr · 2026-04-24T01:08:20Z

Thanks to everyone who contributed to the WebID guidance here — @uvdsl, @csarven, @jeff-zucker, @elf-pavlik, @renyuneyun, and the authors of the Solid WebID Profile — the review comments have meaningfully shaped the shape and tone of this section. I've just pushed a run of commits that work through the open threads (bounded ext-profile traversal, spec-aligned statement filter, refreshed predicate list from dokieli / SolidOS profile-pane, §3.1.4 Security Considerations for solid:oidcIssuer, data-discovery note in §4, section-number cleanup, and a language pass), and resolved each review thread with a reply linking the commit.

If any of the resolutions feel unsatisfactory or a discussion is worth continuing, please flag it on the main Solid26 PR #776 so it can be carried forward and resolved there.

jeswr added 2 commits April 19, 2026 11:33

feat: boostrap webid section

0e5cf2c

feat: enhance Solid26 guidance sections

8d3dbe4

fix section headings

d10c409

feat: enhance WebID Profile guidance with additional validation notes…

8ed92e9

… and refined predicate listings

jeff-zucker reviewed Apr 19, 2026

View reviewed changes

Comment thread solid26.html Outdated

jeff-zucker reviewed Apr 19, 2026

View reviewed changes

Comment thread solid26.html Outdated

jeswr added 2 commits April 19, 2026 17:31

feat: update WebID Profile note to include empirical data source for …

8dbd916

…predicate usage

feat: add clarification on non-public WebID Document retrieval in Web…

39dfce9

…ID Profile

jeswr force-pushed the feat/solid26-webid branch from 9099764 to 39dfce9 Compare April 19, 2026 16:48

csarven reviewed Apr 19, 2026

View reviewed changes

minor editorial

afa3173

uvdsl requested changes Apr 20, 2026

View reviewed changes

csarven reviewed Apr 20, 2026

View reviewed changes

Comment thread solid26.html Outdated

csarven reviewed Apr 20, 2026

View reviewed changes

Comment thread solid26.html Outdated

chore: consistency of term "Implementors Guide" with main PR

4bc6ca3

Co-authored-by: Christoph Braun <braun@kit.edu>

This comment was marked as resolved.

Sign in to view

uvdsl force-pushed the feat/solid26-webid branch from a67f2f7 to 4bc6ca3 Compare April 21, 2026 11:55

update this PR with upstream changes from the main Solid26 (unrelated…

77c44e1

… to WebID)

jeff-zucker reviewed Apr 21, 2026

View reviewed changes

Comment thread solid26.html Outdated

fix foaf predicate and note on solid:oidcIssuer

c2c5b24

jeff-zucker reviewed Apr 21, 2026

View reviewed changes

Comment thread solid26.html

jeff-zucker reviewed Apr 21, 2026

View reviewed changes

Comment thread solid26.html Outdated

jeswr and others added 23 commits April 23, 2026 14:29

chore: remove mention of profile shapes

8f0c801

Co-authored-by: Christoph Braun <christoph.braun@protonmail.com>

Tighten WebID term definitions in §3.1

e55840d

Use "HTTP URI" for the WebID definition to match the normative section. Drop "Web resource" (not an established term) and the "Generally public / permissioned" hedging; state the auth property precisely where it matters.

Drop 'publicly readable' qualifier in assembly step 1

86880ff

Visibility of the WebID Document is covered in §3.1.2. Step 1 only needs to surface an error when retrieval fails.

Require both text/turtle and application/ld+json for WebID Profile Do…

3f512f2

…cument Align with Solid WebID Profile §3.1 Reading Profile, which extends WebID 1.0's Turtle-only requirement to include JSON-LD.

Refresh profile-editor list: drop PodBrowser, add dokieli

c8f9754

PodBrowser is no longer actively maintained; dokieli is a widely-used reader/writer of agent profiles.

Drop unused [BIO] reference

7743a51

[BIO] was listed in §References but never cited in the document.

Surface error when WebID lacks solid:oidcIssuer

db43d1e

A WebID without an oidcIssuer cannot authenticate via Solid-OIDC; clients should tell the user rather than failing opaquely further into the login flow.

Call out that missing Preferences/Type Index documents are not errors

eab3e45

Not all WebIDs link a Preferences Document or Type Index documents; clients should skip their fetch silently rather than fail.

Use 'set union' in WebID Profile definition and assembly algorithm

52f9e14

Note the range of data-discovery mechanisms beyond the profile

be009c2

Client-side data discovery varies across the ecosystem; list the common mechanisms (Type Indexes, SAI, SPARQL / Quad Pattern Fragments endpoints, fixed paths under storage root, DCAT) without prescribing one.

Soften predicate-list framing to 'fallbacks to consider'

5acc54a

Drop the SHOULD-accept-as-equivalent normative framing; present the list as optional fallbacks applications may consider.

Drop section numbers from external spec references

37b720d

Per csarven (PR #781) and jeswr's agreement: section numbers in referenced specs are not reliable across snapshots. Keep link text as the section title only; internal cross-references within this document keep their numbers.

Soften security-note framing and restore absent-link prose

656d603

Use 'Not all Solid servers implement this protection' rather than 'No known Solid server', and restore the fuller wording about Preferences/Type Index documents being absent.

Extend WebID Profile definition to match algorithm sources

878ec35

The assembly algorithm unions statements from the Preferences Document and Type Index documents as well as Extended Profile Documents; the term definition now names all four sources.

jeswr marked this pull request as ready for review April 24, 2026 01:05

jeswr merged commit 2076240 into solid26 Apr 24, 2026

jeswr deleted the feat/solid26-webid branch April 24, 2026 01:06

csarven mentioned this pull request Apr 24, 2026

feat: initialise Solid26 implementors guide #776

Draft

Conversation

jeswr commented Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jeff-zucker commented Apr 19, 2026 via email

Uh oh!

jeswr commented Apr 19, 2026

Uh oh!

Uh oh!

Uh oh!

csarven left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

elf-pavlik commented Apr 19, 2026

Uh oh!

jeswr commented Apr 19, 2026

Uh oh!

uvdsl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as resolved.

This comment was marked as resolved.

Uh oh!

Uh oh!

Uh oh!

elf-pavlik commented Apr 22, 2026

Security of solid:oidcIssuer

Privacy for Type Indexes

Uh oh!

jeff-zucker commented Apr 22, 2026

Uh oh!

elf-pavlik commented Apr 22, 2026

Uh oh!

jeswr commented Apr 24, 2026

Uh oh!

jeswr commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

jeswr commented Apr 19, 2026 •

edited

Loading

Security of `solid:oidcIssuer`

jeswr commented Apr 24, 2026 •

edited

Loading