Add solid:proxy to Solid Terms

[csarven]

Resolves #26 after taking feedback into account. This proposal is more generic than the one in the issue so that it can essentially be used by any thing that wishes to advertise a proxy endpoint. It was initially proposed as an agent's preferred proxy but it can also be advertised by a storage as mentioned in the issue, as well as the use case as part of communication options mentioned in storage description: solid/specification#355 (comment)

https://dokie.li/ (source: https://github.com/dokieli/dokieli ) has implemented solid:preferredProxy, and if this PR is accepted, there are no issues (or barriers) to make the change to solid:proxy immediately.

Applications such as dokieli get around CORS limitations (either servers not participating or not implemented properly) on the Web by using user's preferred proxy, which acts as a fallback. In addition to that, the user can also hide their application's Origin.

The notion of an agent/actor having a reliable proxy is also mentioned in specifications such as ActivityPub: https://www.w3.org/TR/activitypub/#proxyUrl

An open source Solid server such as NSS ( https://github.com/nodeSolidServer/node-solid-server/ ) has implemented the proxy from earlier on.

[elf-pavlik]

Shouldn't the term first be used by one of the work items on https://solidproject.org/TR ?

[csarven]

I believe it would already be covered by Solid WebID Profile and Solid Protocol. It is implied with respect to the use cases as already mentioned.

It is obviously optional for any resource to advertise solid:proxy and also optional for any application to use it. We can drop the property into Solid WebID Profile (or even Solid Protocol or something else). I can also draft a proposal for a new work item "Solid Proxy".

---

I'd be curious to know everyone's experiences with respect to CORS enabled servers on the web, and whether they consider it to be a non-issue for Solid applications. Alternatively, whether servers not supporting CORS is outside of the scope of the Solid ecosystem. Or, whether a proxy endpoint is not practical for any applications in order to access arbitrary resources on the web when they encounter issues with CORS.

We can also wait for the blessing of a "Solid Use Cases and Requirements" document before formally acknowledging what all this is about before merging this PR.

If you would like to apply a particular criteria, please do propose one that we can evaluate; put in place; and then apply equally to all proposals - including the merging of this PR.

---

As the author of https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#vocabulary-management and the creator of this repository, I'm fairly aware of the concerns and related processes. If people are on board, great!

[elf-pavlik]

I'm not objecting to this PR; I just want to clarify the order of actions leading to adding a new term.

https://solidproject.org/TR/protocol#cors

The section above covers CORS in the context of interop between solid apps and storage.
If advertising a proxy is part of a proposal to address other requirements from a use case in the scope of Solid CG, it is preferable to add that requirement to the relevant proposal first and then reference it in the PR requesting inclusion in the vocabulary.

We could apply that order to #93 and any other PR if that's a reasonable order.

BTW, I will propose both PRs for the agenda of next week's CG meeting.

[csarven]

Awesome. I'd like to invite everyone to also review solid/webid-profile#118 - adds a section on Proxy to Solid WebID Profile that mentions the concerns and needs / use cases that I've outlined in the original issue in this PR and elsewhere (for a number of years now) - which is also backed by implementation experience.

[csarven]

Once again, the Solid WebID Profile and Solid Protocol specifications already address the need for accessing cross-origin resources (not necessarily limited to those hosted by a Solid server) as well as the importance of user privacy and security, or at the very least, they make an effort to improve it.

If there is an alternative to a proxy that is comparable or practical for applications, we can evaluate that requirement when it arises. Until then, to the best of my knowledge, there is no established process that sensibly poses a barrier here. I've tried to tick as many boxes as I can as open and transparent as I possibly can.

As of this comment, the needs are clearly outlined, there is a proposal for a specification ( solid/webid-profile#118 ) and there is some implementation experience with proxies in Solid. Let me know if other present or past proposals have also met these criteria. If not, let's avoid burdening this PR with non-existing processes that should be adapted. That said, I encourage you to draft a proposal in writing and submit it for acceptance by the Solid CG. From my perspective, based on the evidence provided, this is not a dependency for this PR.

[csarven]

@TallTed , can you please have a look at this (beyond the language)?

@Otto-AA , please have a look since you've raised #26 (comment) and I want to make sure something like this is adequate. Simplicity over flexibility however.

[csarven]

Alternative where the path is irrelevant, and what's most important is the query parameter "proxy" for servers to consider. It should not matter for the application since they'd essentially just concat.

Suggested change

	rdfs:comment """A proxy endpoint for applications to use. The value of the property is intended to be used as the base URL for the request, e.g., the proxy as literal: `https://example.org/proxy?uri=` would be used to request `https://example.net/profile/card#me` as `https://example.org/proxy?uri=https://example.net/profile/card%23me`"""@en ;
	rdfs:comment """A proxy endpoint for applications to use. The value of this property is intended to be used as the base URL for requests, following the URI Template: `{+path}{?proxy}`. For example, the proxy `https://example.org/foo?proxy=` can be used to fetch `https://example.net/profile/card` by making an HTTP request to `https://example.org/foo?proxy=https://example.net/profile/card`."""@en ;

I don't have a strong opinion on this besides it being dead simple for applications, essentially concatenating the resource they want to fetch to the proxy URL.

What I don't like about the above is that existing servers with dedicated resource and accepting requests with a query parameter, e.g., /proxy?uri= will need to be updated. So, prefer to stick to what's currently deployed. In that case we need the URI Template and the example in the rdfs:comment be along these lines:

Suggested change

	rdfs:comment """A proxy endpoint for applications to use. The value of the property is intended to be used as the base URL for the request, e.g., the proxy as literal: `https://example.org/proxy?uri=` would be used to request `https://example.net/profile/card#me` as `https://example.org/proxy?uri=https://example.net/profile/card%23me`"""@en ;
	rdfs:comment """A proxy endpoint for applications to use. The value of this property is intended to be used as the base URL for requests, following the URI Template: `/proxy{?uri}`. For example, the proxy `https://example.org/proxy?uri=` can be used to fetch `https://example.net/profile/card` by making an HTTP request to `https://example.org/proxy?uri=https://example.net/profile/card`."""@en ;

[elf-pavlik]

Those details should be in the relevant specification. This vocabulary term would then link to the relevant section of that specification.

[josephguillaume]

Any thoughts on how the vocab should model securing the proxy?
Presumably the user does not want the general public accessing a proxy they run, and an app would need to know if the proxy is origin or authorisation constrained?

@NoelDeMartin 's Umai uses a proxy to import structured markup from arbitrary websites. In addition to using a POST method instead of GET (which could be changed), it is both rate limited and origin constrained to the apps
https://github.com/NoelDeMartin/umai/blob/main/docs/using-a-proxy.md
https://proxy.noeldemartin.com
https://github.com/NoelDeMartin/proxy

Should the range solid:proxy be overloaded to allow a future Proxy resource that can express this type of thing, or should a more specific name be used to leave the generic solid:proxy open for future use?

The security implications of using a proxy (esp. assumption of trust) should eventually be documented somewhere, though I understand that's not here.

Edit: Looks like this issue came up in the other PR, but it's not clear to me how this vocab will address it