Clarify which issuers are implicitly trusted. #52

RubenVerborgh · 2021-10-25T18:09:18Z

Fixes #51

RubenVerborgh · 2021-10-25T18:12:21Z

index.bs

@@ -350,7 +350,7 @@ With the `webid` scope, the DPoP-bound Access Token payload MUST contain these c

    <pre highlight="json">
    {
-        "webid": "https://janedoe.com/web#id",
+        "webid": "https://jane.doe.example/web#id",


Changed in order to have subdomain examples below

index.bs

RubenVerborgh · 2021-10-25T18:51:25Z

index.bs


 Unless the RS acquires IdP keys through some other means, or the RS chooses to reject tokens issued by this IdP,
 the RS MUST follow OpenID Connect Discovery 1.0 [[!OIDC.Discovery]] to find an IdP's signing keys (JWK).

-### WebID Issuer Discovery via Link Headers ### {#webid-issuer-discovery}
-
-A server hosting a WebID document MAY transmit the `http://www.w3.org/ns/solid/terms#oidcIssuer` values via Link Headers but it MUST be the same as in the RDF representation. A client MUST treat the RDF in the body of the WebID document as canonical but MAY use the Link Header values as an optimization.


I removed this section because it was unclear how this could be enforced.

To me,

A client MUST treat the RDF in the body of the WebID document as canonical

means that the client still has to read the RDF body. So then also checking the header seems pointless.

I.e., I can't think of

MAY use the Link Header values as an optimization

while also enforcing the RDF as canonical.

This can be enforced in cases where a special server understands the issuer claim in a WebID document. A live example of this is at https://id.inrupt.com/acoburn

There are surely ways to express this more clearly in the specification text. But the point is that this is an optional feature that allows a client to avoid having to download and parse an entire RDF profile document.

Okay; will restore. I think the canonical language is void though. No point in having that if it is not mandatory to check.

This can be enforced in cases where a special server understands the issuer claim in a WebID document. A live example of this is at https://id.inrupt.com/acoburn

I did not understand that one though; how is the enforcement happening? Of do you mean that the server enforces this, not the client? Because the language currently reads that the client should do this.

Updated the language.

Or do you mean that the server enforces this, not the client?

It is a resource server, acting as an HTTP client, that enforces this. The language can certainly be clarified.

acoburn · 2021-10-25T19:33:36Z

In a small organization or deployment where an entire domain space is managed by a single person (or small group) this notion of implicit trust makes a lot of sense. Where this breaks down is in cases where a WebID is hosted in a sub-domain space that is managed separately from the root domain.

For example, if company Foo is deploying Solid in such a way that foo.example is the root domain, managed by one group of administrators and solid.foo.example is managed by a separate group of administrators, it is now possible for that first group of administrators to impersonate any agent with a WebID under solid.foo.example.

Another example is with a large hosting provider: bar.example where the Solid users are given a domain at solid.bar.example. Here, the administrators of solid.bar.example have no knowledge or trust of the administrators who manage the bar.example domain, yet the bar.example administrators would be able to impersonate any solid user without any need to access their credentials.

acoburn

I would like to see the results of a threat modeling exercise before approving this. This seems to have some significant security aspects that should be considered carefully.

RubenVerborgh · 2021-10-25T21:04:07Z

Where this breaks down is in cases where a WebID is hosted in a sub-domain space that is managed separately from the root domain.

Thanks, Aaron. I'm more than happy to drop the subdomain relaxation; I only added it because of #51 (comment)

This seems to have some significant security aspects that should be considered carefully.

Agreed; just want to note that this text is describing existing implementations in the wild, not proposing anything new.

Fixes #51

elf-pavlik · 2021-11-03T12:41:12Z

We discussed this PR during the panel meeting yesterday.

First of all, we would like to continue the conversation in #51 to see if we could remove implicit trust altogether and always rely on the explicit statement in WebID Document and/or HTTP Link header of the response when requesting WebID.

If in the issuer we decide that we indeed need some form of implicit trust. It shouldn't just match all the subdomains down to TLD. For example, having WebIDs https://jane.doe.example/web#id and https://alice.doe.example/web#id they might have designated https://doe.example/ to an instance of storage. At the same time, they don't intend to use that storage at https://doe.example/ as their OIDC Issuer. The algorithm for matching subdomains proposed in this PR, would give implicit trust to https://doe.example/ and in practice make it impossible to use https://doe.example in a way that doesn't make it a trusted OIDC Issuer.

elf-pavlik · 2022-02-14T17:40:03Z

#51 (comment) suggests a way forward, this includes closing this PR without mergning

RubenVerborgh added the bug Something isn't working label Oct 25, 2021

RubenVerborgh requested review from elf-pavlik and acoburn October 25, 2021 18:09

RubenVerborgh mentioned this pull request Oct 25, 2021

Clarify implicitly trusted OIDC issuer #51

Closed

RubenVerborgh force-pushed the fix/trusted-issuers branch from 2262ed3 to 656426a Compare October 25, 2021 18:13

RubenVerborgh commented Oct 25, 2021

View reviewed changes

acoburn requested changes Oct 25, 2021

View reviewed changes

RubenVerborgh force-pushed the fix/trusted-issuers branch from 656426a to f033b8b Compare October 25, 2021 21:08

Clarify which issuers are implicitly trusted.

d3c1614

Fixes #51

RubenVerborgh force-pushed the fix/trusted-issuers branch from f033b8b to d3c1614 Compare October 25, 2021 21:09

elf-pavlik closed this Feb 16, 2022

acoburn deleted the fix/trusted-issuers branch March 29, 2022 20:27

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarify which issuers are implicitly trusted. #52

Clarify which issuers are implicitly trusted. #52

RubenVerborgh commented Oct 25, 2021

RubenVerborgh Oct 25, 2021

RubenVerborgh Oct 25, 2021

acoburn Oct 25, 2021

acoburn Oct 25, 2021

RubenVerborgh Oct 25, 2021

RubenVerborgh Oct 25, 2021

acoburn Oct 25, 2021

acoburn commented Oct 25, 2021

acoburn left a comment

RubenVerborgh commented Oct 25, 2021

elf-pavlik commented Nov 3, 2021

elf-pavlik commented Feb 14, 2022

Clarify which issuers are implicitly trusted. #52

Clarify which issuers are implicitly trusted. #52

Conversation

RubenVerborgh commented Oct 25, 2021

RubenVerborgh Oct 25, 2021

Choose a reason for hiding this comment

RubenVerborgh Oct 25, 2021

Choose a reason for hiding this comment

acoburn Oct 25, 2021

Choose a reason for hiding this comment

acoburn Oct 25, 2021

Choose a reason for hiding this comment

RubenVerborgh Oct 25, 2021

Choose a reason for hiding this comment

RubenVerborgh Oct 25, 2021

Choose a reason for hiding this comment

acoburn Oct 25, 2021

Choose a reason for hiding this comment

acoburn commented Oct 25, 2021

acoburn left a comment

Choose a reason for hiding this comment

RubenVerborgh commented Oct 25, 2021

elf-pavlik commented Nov 3, 2021

elf-pavlik commented Feb 14, 2022