solid26: WebID Guidance

[jeswr]

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]

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]

Link fixed @jeff-zucker - thanks for catching!

[jeff-zucker]

For a normative view, that is probably sufficient, but for a practical guide to implementers, there are several things we should mention in the interest of preventing excessive loading. 1) What happens with seeAlso references inside seeAlso files? Implementers should be warned to prevent multiple loading and loops if, e.g., seeAlsoA both references and is referenced by seeAlso B. Also, to what depth does one descend? Personally, I think users should be warned against long chains of seeAlsos containing seeAlsos 2) I also think that users should be warned not to depend on information in sameAs links - that a client may want to read the specific profile they requested, not all the user's profiles. If someone gets to my software-dev profile, they may or may not want to include my fire-dancing profile.

[jeswr]

What happens with seeAlso references inside seeAlso files?

My interpretation of https://solid.github.io/webid-profile/#discovery is that there are two locations you look for seeAlso references:

• The WebID Profile Document
• The preference document

and that one should not recursively look up extended profiles from extended profiles, nor type indexes from typeindexes.

If this is the case, I can clarify the text here - "transitively" - is a bad word for me to be using in this context. If this is not the correct interpretation / not what is done in practise - I am happy to update here. We should probably also clarify that in https://solid.github.io/webid-profile/

2. I also think that users should be warned not to depend on information in sameAs links - that a client may want to read the specific profile they requested, not all the user's profiles. If someone gets to my software-dev profile, they may or may not want to include my fire-dancing profile.

Interesting ... I had always thought about profiles a bit like how google chrome operates at the moment. Each profile corresponds to a different WebID (equivalently email when one is using chrome), and that is how you make the distinction.

Are there live examples of these different profiles within one Pod? If so, what are the context hints available; do we need to know the origin document / named graphs to know which statement comes from which profile? Are there other modelling hints?

[jeff-zucker]

My interpretation of https://solid.github.io/webid-profile/#discovery is that there are two locations you look for seeAlso references:

There is one problem with your interpretation (and perhaps with our original doc): if the WebID Document is hosted outside of Solid, one needs one of those predicates to get from there to extended profile documents. If any Solid app is to be able to write seeAlso documents (seems like an important function for Solid Apps to be able to do) , in this case, they can't put a pointer to the seeAlso in the WebID doc because it is not on a Solid Resource server. Therefore the only place they can put a pointer to their new seeAlso is in a seeAlso.

[jeff-zucker]

To accommodate this need for a place to write pointers to seeAlsos, my load-profile app descends exactly two levels of seeAlsos - from the WebID doc to a seeAlso and from there to any seeAlso it lists, but not seeAlso's listed in the second set of seeAlsos.

[jeff-zucker]

Are there live examples of these different profiles within one Pod?

Not that I know of and I believe there are so many unknowns about what that would cause that we should either warn against it or perhaps better just not mention it.

I was talking about sameAs pointers to profiles on other pods or in non-pod location like Wikipedia. To be frank, these are not widely used - Tim and Kingsley have many and almost no one else has any.

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

[csarven]

The implementation reports normally mention software, so it may not be particularly meaningful to list them in this kind of a document.

Otherwise, please add dokieli (source) to the list. Dokieli makes use of a wide range of information about agents, their additional/extended profiles, assets, preferences, policies, as well as their social connections. It also makes use of variety of equivalent properties.

Also agree with earlier comments that referencing abandoned software, like PodBrowser, is neither useful or attractive.

[csarven]

I'll use this as an example but it holds true for this whole list. Stating that vcard:hasPhoto has higher priority than foaf:img is not accurate. It may be the case for ODI or SolidOS (or wherever it is pulled from) but that's not universally agreed upon by all implementations. In fact, clients are more robust when they can take into several of them into account to cater for different circumstances. For instance, dokieli in fact makes use of the following properties in this order:

      ns.as.image,
      ns.as.icon,
      ns.foaf.img,
      ns.schema.image,
      ns.vcard.photo,
      ns.vcard.hasPhoto,
      ns.sioc.avatar,
      ns.foaf.depiction

I suspect that others implementations may have a different order given their application environment.

So, what I suggest here is a recommendation that makes it clear that there consumers and writers of WebID may encounter or need to create different properties/classes depending on their area of application. This is typically accompanied with Protocols and Data Models that are used alongside Solid Protocol and Solid WebID Profile. And lastly, applications may consume from a range of terms but they may write in a particular one.

It is not so clear cut at as e.g., use hasPhoto if not image.

[csarven]

Guide the implementer here. Tell them that a WebID in a Solid storage guarantees certain affordances for reading and writing with the support of Solid Protocol.

[csarven]

This is either redundant or underspecified. It is redundant because it talks about a base WebID Profile Document. It is underspecified because it completely overlooks what Solid WebID Profile says: https://solid.github.io/webid-profile/#reader-application-webid-profile , including JSON-LD. Again, related to the server that's behind it, and that Solid server provides some expectations.

[csarven]

This should also list ldp:inbox given that:

• Solid WebID Profile refers to it: https://solid.github.io/webid-profile/#webid-profile-data-model and it is on equal requirement as some other properties like storage.
• Solid Protocol refers to LDN for servers and clients: https://solidproject.org/TR/protocol#linked-data-notifications .
• Data at https://jeff-zucker.github.io/solid-load-profile/ indicates there is substantial amount of deployments out there using it (context: e.g., foaf:name 76, solid:oidcIssuer 71, ldp:inbox: 66, space:storage 64, solid:publicTypeIndex: 64, foaf:knows 53).
• An agent's inbox contributes towards the "social" aspect of Solid.
• ActivityPub's as:inbox aliases ldp:inbox, so there is a wider interop opportunity when they are used interchangeably depending on the context.
• ...

[csarven]

I don't find this framing helpful. The purpose of solid26 is not about what's referenced from the "pinned specifications". The frame is about what's useful for implementers from the https://solidproject.org/TR/ so they can build useful tools. I suggest expressing this paragraph differently. It should be about why do we need a WebID Profile document? What is it useful for? What are the use cases? It should capture the essence of use cases: https://solid.github.io/webid-profile/#use-cases

[csarven]

Is this information useful or need to be mentioned for implementers?

[csarven]

I don't quite follow why this is here.

[csarven]

This whole utterance of "pinned specification" is undermining the purpose of things. There is no value to the reader other than potentially causing confusion. They need to know that either this document is sure / confident about what should be implemented / encouraged and what is not encouraged. Not: "oohh, you know, if you really want to use it, go for it, I guess, but just sayin' that it is not part of the pinned specifications club that we pulled out of thin air..."

[elf-pavlik]

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]

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!