solid / solid/solid-oidc

OIDC issuer discovery when WebID is not publicly readable

Open
#80 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Bikeshed
Stars
26
Forks
14
PR merge metrics
No merged PRs in 30d

Description

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the WebID draft's Privacy section and the interop discovery reference using interop:hasAuthorizationAgent. Review the linked discussion about HTTP Link headers, publicly readable WebID Documents, and protected references lists. Done means reaching and documenting a decided issuer-discovery requirement for non-public WebID Documents.

Written by the indexing model from the issue text.

Assessment

Domain
authentication
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.