You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current specification, the section on Link headers says that "a client MUST treat the RDF in the body of the WebID Profile as canonical."
Is there a specific reason for this decision?
I am asking because having the Link header as canonical instead would allow for an easier integration of this (non-writable) technical information with the (preferably writable) content of a Solid Profile.
The text was updated successfully, but these errors were encountered:
I think the reason for this is that since the information will technically be duplicated in two different places, in case of misalignment (which the spec forbids, but better safe than sorry), the spec making one data source explicitly authoritative over the other prevents interoperability issues. The WebID being the source of truth for claims other than the OIDC Provider trusted by the owner, it makes sense that it is also authoritative for this specific claim.
In any case, spec-conforming servers should have the same values in both places, so hopefully this specific requirement shouldn't be something the clients have to worry about too much.
The reason I think it is advantageous to turn this around, is that you can make a distinction in authorative data between social data, that is not sensitive to changes with any user-agent (e.g. foaf:name), and technical data that is sensitive because an incorrect change could easily lock the user out (e.g. oidc:issuer).
The first I would leave in the document, the second I would (preferably) send as Link headers with the document.
In the current specification, the section on
Link
headers says that "a client MUST treat the RDF in the body of the WebID Profile as canonical."Is there a specific reason for this decision?
I am asking because having the
Link
header as canonical instead would allow for an easier integration of this (non-writable) technical information with the (preferably writable) content of a Solid Profile.The text was updated successfully, but these errors were encountered: