Clarify implicitly trusted OIDC issuer

[RubenVerborgh]

No description provided.

[timbl]

That discussion was just noticing that existing normal NSS users all log in happily without having that ?webid <http://www.w3.org/ns/solid/terms#oidcIssuer> ?iss. triple in their profile.

[acoburn]

Thanks @RubenVerborgh

1. Why MUST the WebID always be dereferenced, even if the iss claim matches the domain of the WebID?

In this case, I don't see why the WebID would need to be dereferenced.

2. The current language is ambiguous. It states that "if the iss claim is different from the domain of the WebID", but this precondition will always fail if taken literally.

This is an excellent point. Here we would want to clarify that the URIs would need to match the scheme and port. And that the host needs to either match or be a subdomain of the issuer.

Do we accept both https://example.org and https://example.org/ (with slash)?

This case in particular has been the cause of many errors, especially when comparing the iss claim with the solid:oidcIssuer URI in a user's WebID profile. Personally, I'd like to clarify that https://example.org and https://example.org/ be treated as equivalent.

Do we accept an iss of https://example.org/arbitrary/path, which does have the same domain?

This is not something I have considered before. A path like this implies a multi-tenant IdP, so might want to be more careful with this case, but if the scheme/host/port values are the same (or subdomains) of the WebID, there is already an implied trust relationship. And so I do not see why that would be any different that the cases outlined above.

3. Apart from the ambiguity, the old mechanism's behavior was to also trust parent domains. So if the WebID was on a subdomain, then it's parent domain(s) would be trusted as well. Is this desired behavior or not.

Yes, I believe this is desired behavior (that parent domain(s) are trusted).

[elf-pavlik]

We had some conversation about it during today's solid/authentication-panel#197

It seems that having an implicit trust can be useful for two reasons

1. RS doesn't need to fetch and parse WebID Document
2. WebID Document doesn't need to include explicit triple.

While the first one seems pretty minor, I would like to understand when the second becomes important. @acoburn mentioned that in his implementation of IdP, in WebID Documents that it manages it does include that explicit triple.

Since we need to have that explicit mechanism with solid:oidcIssuer I think it's worth considering if we should keep the added complexity by having an implicit mechanism. If we find the strong requirement to have an implicit mechanism we would need to define it in detail, including subdomains, ports, paths etc. I'm worried that this may lead to dependency on something like https://publicsuffix.org/ if we need to match subdomains.

[elf-pavlik]

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

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

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

[elf-pavlik]

During the call yesterday @acoburn suggested the even if WebID Document is not public, HTTP response could still include OIDC Issuer delegation in Link Header. Currently, we have it defined as an optional way of advertising it but we could consider making it required if the document itself is not public.

@jeff-zucker I think it would be great to consider implications of WebID Document not being public in the Task Force working standards predicates used there. Personally, I would lean in the direction to require it to be public and provide a clear way how to extend it with non-public information. I would prefer not to dive into that too deep here and discuss it wherever the Task Force focused on WebID Document will work.

[csarven]

Lower level: w3c/WebID#1

[elf-pavlik]

In case when the user makes their WebID profile private. Unless we provide explicit solid:oidcIssuer delegation in Link Header, the User would need to provide the URL of their OP/Issuer to the Client. Otherwise, the Client wouldn't be able to discover OP/Issuer based on the User's WebID.

[matthieubosquet]

To be considered maybe is the fact that (in my understanding):

1. The existence of a WebID is justified by it being used to assert control over a URI and therefore the data used to assert such control by nature doesn't seem to be private (OIDC issuer/public key...);
2. There is no restrictions about WebIDs forbidding anyone to link them to any number of public and/or private profile documents.

See also a detailed example: w3c/WebID#1 (comment)

[matthieubosquet]

Also, I'm not an expert, but I can imagine that there are cases where someone wouldn't want to trust an issuer on the same domain as their WebID or even subdomain. I am therefore against implicit trust, it doesn't seem to solve any technical issues and introduces security concerns, sounds like a bag of crabs to me.

[elf-pavlik]

#80 captures discussed specific case where WebID Document wouldn't be public

#79 will remove any notion of implicit trust and links to #80 inline

Can we close this issue?

#52 would not be merged and simply closed