solid
Add solid:proxy to Solid Terms
Resolves https://github.com/solid/vocab/issues/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: https://github.com/solid/specification/issues/355#use-cases
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.
Shouldn't the term first be used by one of the work items on https://solidproject.org/TR ?
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!
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.
Awesome. I'd like to invite everyone to also review https://github.com/solid/webid-profile/pull/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.
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 ( https://github.com/solid/webid-profile/pull/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.
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
