Conversation
Adds §8 with one subsection (Impact of not enforcing Protected Properties) covering the consequences when a server does not enforce the Protected Properties requirement: the WebID owner's solid:oidcIssuer can be rewritten by an agent with write access to the WebID Document, opening the way to impersonation. Also adds the matching TOC entry. Raised in response to discussion on solid/specification#776, where the underlying gap was first noted.
Match the rest of the document's pattern: subsection h3 carries an explicit <bdi class="secno">8.1</bdi>, and the TOC nests the subsection entry under §8.
The two bullets above already convey the impact; the trailing client-trust advisory adds nothing not derivable from them.
|
Thanks for putting this together @jeswr . I want to be honest with you, though: the phrasing and structure of this PR (and other issues/comments generated in the past weeks) read as largely LLM-generated, and the cadence at which they're appearing makes me wonder how much review is happening between generation and posting. I'd point you to the W3C Advisory Board's recent note on this: https://www.w3.org/TR/llms-standards/#where-risks-may-outweigh-benefits, particularly the sections on subtle incorrectness, verbosity, and "second-hand burdening," plus the guidance in §3 on labelling LLM output and assuming full responsibility for it. I think it's worth a read. My timeline here doesn't match the pace you're working at, and I don't have the bandwidth to act as a reviewer-of-record for output that hasn't been thoroughly checked by the person submitting it. Could you take another pass through this PR, ideally rewriting in your own words where the LLM phrasing is doing the heavy lifting, and verifying the technical claims hold, and re-open or update once you're confident standing behind it line by line? Happy to engage properly once that's done. |
2 participants
A preview link can be found here.
Summary
Adds a new §8 Privacy and Security Considerations section (non-normative) with one subsection: Impact of not enforcing Protected Properties. The Solid WebID Profile draft currently does not include any Privacy or Security Considerations section.
Why
The Protected Properties requirement is intended to prevent agents other than the WebID owner from modifying properties such as
solid:oidcIssuer. Most server implementations do not currently enforce this. The new subsection makes the consequences of non-enforcement explicit:solid:oidcIssuer, redirecting Solid-OIDC authentication to an attacker-controlled OpenID Provider and impersonating the WebID owner.The same point has been added downstream to solid26 §2.5 in solid/specification#776, but the upstream home for considerations of this kind is here.
Scope
Deliberately narrow — one subsection on Protected Properties non-enforcement. Further considerations (e.g. trust in hosting server beyond Protected Properties, public dereferencing implications) can be added as follow-up PRs.
Test plan
index.htmland confirm §8 Privacy and Security Considerations appears between §7 Other predicates and the Changelog appendix.#privacy-and-security-considerations,#impact-of-not-enforcing-protected-properties,#protected-properties) resolve.