Conversation
|
This relates to our conversation from last week CG call which we will continue next Wednesday. Which class of product this requirement is placed on? Currently there is no requirement for hosting WebID Documents in Solid Storage. Besides minutes from last week CG call there is also this discussion: I agree that this should be required somewhere, my main point is that it isn't clerar how to forumate it in terms of classes of products. |
|
In WebID there is non-normative https://www.w3.org/2005/Incubator/webid/spec/identity/#privacy
We should probably also check how this is addressed in |
There was a problem hiding this comment.
PRs above correction class 1 should target ED/protocol.html not TR/protocol.
This change adds a requirement for WebID Profile Documents to be dereferencable 'publicly'.
There is no need to set this constraint on the Solid Protocol. If necessary, it can be done where it needs to be done in specifications that actually need it.
It is possible that a valid #Server does not have a URI designated as a WebID. The specification merely explains that WebIDs are common and significant resources for which servers provide a representation.
uvdsl
left a comment
uvdsl
left a comment
There was a problem hiding this comment.
There exist use cases where a WebID profile document is not necessarily public.
For example, in a corporate context (see Project MANDAT), an employee's WebID profile does not need to be publicly accessible by anyone from the Web. It is sufficient for the WebID profile to be accessible by the corporate servers, be it a Corporate Solid Server or a Corporate Rights Delegation Proxy. An organization is thus able to keep their employees' WebID profiles visible only to the internal systems.
I question whether requiring a WebID profile to be publicly accessible / readable is a necessity.
- Intent of WebID 1.0: This is speculative. The corresponding section covers privacy aspects and does not clearly present that a document is necessarily public. It is a non-normative section after all.
- overwhelming practice: There is no necessity to require something that most implementations do and that would prevent other use cases to be facilitated.
- Solid-OIDC does not have an implicit requirement for a WebID profile document to be public. Solid-OIDC merely relies on the WebID profile document being accessible to all involved clients and servers. But this does not mean that the profile document must be public. This is a difference that matters in corporate environments. In the use case outlined above (Project MANDAT), the organization might use Solid-OIDC completely internally for their employees to authenticate at a (Rights Delegation) Proxy. There is no requirement for the WebID profile document of an employee to be public here.
I would like to suggest to clarify - if at all - in a non-normative paragraph that it is strongly encouraged to have WebID profile documents publicly accessible such that the agent may participate in the Solid ecosystem on the Web while acknowledging that there might exist (niche?) use cases where publicly accessible WebID profile documents are not desirable or would come with additional use-case-specific requirements.
|
I added it to the agenda of our weekly CG call |
4 participants
Current section 9.1 mentions WebID as "underpinning component" and "used as the primary identifier" in Solid.
This change adds a requirement for WebID Profile Documents to be dereferencable 'publicly'.
WebID 1.0 (section 5.4 Privacy) says
but does so in a non-normative section.
This change aims to improve interoperability by adding a normative requirement which corresponds to both