Add Proxy section

[csarven]

Adds a section for Proxy.

Touched by the following use cases mentioned in https://solid.github.io/webid-profile/#use-cases :

• Communication and use of multiple profiles for different purposes.
• Anonymous, pseudonymous, and meronymous profiles.
• Compilation of preferences, choices, activities and interactions of an agent.

See also solid/vocab#94 for adding solid:proxy to Solid Terms.

---

Preview | Diff

[VirginiaBalseiro]

Looks good.

As a side note, HTML Diff appears to not be working properly. Checked and it's the same for other older PRs where we used it, so perhaps something has changed.

[elf-pavlik]

I think this is a reasonable starting point. As a separate issue I would like to discuss how to prevent a random users to use other user's proxies trying to obscure illegal activities. For example downloading copyrighted content, or accessing content related to abusing children etc.

[csarven]

I agree, that's an important and separate matter. My understanding is that the proxy resource ought to require authentication. I think if the proxy is hosted on a Solid server, that'd be relatively straight forward to protect. Irrespective to where the proxy is, the concern can be mentioned as a note. I can update this PR to reflect that but I think it has to do with a recommendation for servers offering the proxy feature.

[josephguillaume]

I would support mentioning security in some form to avoid normalising use of unsecured proxies.

If this is in the profile document, the implication is that the agent trusts the proxy, but the reality of convenience is that an agent and app may well use whatever is available to get around cors restrictions, without actually thinking about the consequences of a mitm attack.

Even if the agent trusts the proxy, the app may not trust it, and may therefore want to avoid using it in a higher risk context, e.g. the app being seen to be trying to access illegal information.

The agent also does not automatically trust every app wanting to use the proxy endpoint, as noted above.

I'm not a security expert, which increases my desire for a spec to draw my attention to possible risks I may have overlooked.

[elf-pavlik]

I assume the proxy would only access public read data and never pass credentials. If data requires authorization, it will be on the Solid pod and willn't need a proxy. A requirement for the proxy should be added - never to send any user credentials.

[csarven]

Even if the agent trusts the proxy, the app may not trust it, and may therefore want to avoid using it in a higher risk context, e.g. the app being seen to be trying to access illegal information.

In such scenario, it would be the proxy server that will be trying to access illegal information, and the server that is receiving the request from the proxy server is not aware of the application.

That aside, the same argument can be made for using an OIDC Issuer that is involved in illegal activities, so I've created solid/security-considerations#21

The agent also does not automatically trust every app wanting to use the proxy endpoint, as noted above.

In the same way agent not automatically trusting any information that makes it on to their screen through the application? How is that being measure or evaluated in other scenarios?

I assume the proxy would only access public read data and never pass credentials. If data requires authorization, it will be on the Solid pod and willn't need a proxy. A requirement for the proxy should be added - never to send any user credentials.

First of all, this specification is not concerned with how a proxy server should be configured, in the same way it is not suggesting that the Solid WebID Profile server shouldn't be sending user credentials to third parties. Nor do we say an Solid OIDC Issuer shouldn't be sending user credentials to third parties without user's consent.

Second of all, in all likelihood, a trustable / reliable proxy is going to require authentication, otherwise it'll be an open proxy. Irrespective to how a proxy is configured, what proxy an agent trusts, or what proxy an application defaults to (built-in) should be used, isn't something this specification can dictate.

---

I've added the following text based on the feedback ( 58d527f ):

An agent's preferred or trusted proxy may not align with their application's. The decision of whether and in what contexts to use any proxy is an evaluation and a balance between the needs of the agent and the application.

Is that adequate for now?

[josephguillaume]

Second of all, in all likelihood, a trustable / reliable proxy is going to require authentication, otherwise it'll be an open proxy. Irrespective to how a proxy is configured, what proxy an agent trusts, or what proxy an application defaults to (built-in) should be used, isn't something this specification can dictate.

I'm happy with the edit in that it hints that not all proxies are suitable.
Any recommendations on other specs/reading regarding appropriate proxies? The use of proxies with Solid to avoid cors restrictions seems rather different to many other use cases.

[elf-pavlik]

First of all, this specification is not concerned with how a proxy server should be configured

If this draft only focuses on service discovery, including the proxy, there should be a draft that puts some requirements on that proxy. I also suggested that in the PR to the vocab since vocabs don't include normative requirements.

[TallTed]

If data requires authorization, it will be on the Solid pod and willn't need a proxy.

Mightn't the data be spread across multiple pods? I can't think of any reason why a user should be required to have all their apps and/or data hosted in/by a single pod. This leads me to think that some app and/or data requiring authorzation could be on a different pod and therefore need such a proxy.

[elf-pavlik]

I meant that the access-protected data would be across variuos solid storage servers, which would set the needed CORS headers since the solid protocol requires it https://solidproject.org/TR/protocol#cors-server

To my understanding, the use case concerns in-browser apps that use public-readable linked data and can't rely on the servers hosting that data (non-solid storage servers) setting correct CORS headers.

[josephguillaume]

To my understanding, the use case concerns in-browser apps that use public-readable linked data and can't rely on the servers hosting that data (non-solid storage servers) setting correct CORS headers.

In addition to CORS headers, we also have the case where an in browser app using https wants to access linked data via http and is prevented from doing so by browser security rules.