Capturing from #51

@elf-pavlik: I think it's worth considering if we should keep the added complexity by having an implicit mechanism.

@RubenVerborgh: A reason for that would be: what if the WebID is not publicly accessible, or a least not accessible by the IdP?

@elf-pavlik: Are all components for the specification being designed in a way that doesn't depend on publicly accessible WebID Document?

@RubenVerborgh: Let me phrase it differently: I don't think many depend on it.

Curren WebID draft has non-normative statement in Privacy section

A WebID Profile is a public document that may contain public as well personal information about the agent identified by the WebID. As some agents may not want to reveal a lot of information about themselves, RDF and Linked Data principles allows them to choose how much information they wish to make publicly available. This can be achieved by separating parts of the profile information into separate documents, each protected by access control policies.

This suggests the assumption of WebID Document being public read.

@acoburn suggested during today's meeting that Solid-OIDC could require WebID Document to be publicly read.

We also discussed during one of past meetings that if WebID Document isn't public, the HTTP Link header of the response would still need to include a statement for each issuer.

@jeff-zucker are there any other places where the assumption of WebID Document being public read (or not) are discussed?

Interop spec also relies on the discovery of Authorization Agent from public read WebID Document (interop:hasAuthorizationAgent).

The mentioned suggestion in the current WebID Draft could be served by References Lists we work on in interop panel solid/data-interoperability-panel/issues/174 That would allow discovering separate protected resource which for example would include all the statements where WebID is the subject and foaf:knows the predicate. /cc @justinwb