Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add notion of "owner" and requirements #264

Merged
merged 2 commits into from
Jun 16, 2021
Merged

Add notion of "owner" and requirements #264

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
53d4bd0
Add notion of "owner" and requirements
csarven May 19, 2021
e52176c
Revise owner definition and its use by server
csarven May 19, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions protocol.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -334,6 +334,8 @@ <h3 property="schema:name">Definitions</h3>

<p>A <dfn class="dfn-paneled" data-dfn-type="dfn" id="solid-app">Solid app</dfn> is an application that reads or writes data from one or more <a data-link-type="dfn" href="#data-pod" id="ref-for-data-pod">data pods</a>.</p>

<p>An <dfn class="dfn-paneled" data-dfn-type="dfn" id="owner">owner</dfn> is a person or a social entity that is considered to have the rights and responsibilities of a data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed.</p>
csarven marked this conversation as resolved.
Show resolved Hide resolved

<p>A <dfn data-dfn-type="dfn" id="read-operation">read operation</dfn> entails that information about a resource’s existence or its description can be known. [<a href="https://github.com/solid/specification/issues/149#issue-568433265" rel="cito:citesAsSourceDocument">Source</a>]</p>

<p>A <dfn data-dfn-type="dfn" id="write-operation">write operation</dfn> entails that information about resources can be created or removed. [<a href="https://github.com/solid/specification/issues/126#issuecomment-569920473" rel="cito:citesAsSourceDocument">Source</a>]</p>
Expand Down Expand Up @@ -434,6 +436,8 @@ <h3 property="schema:name">HTTP Client</h3>
<section id="uri" inlist="" rel="schema:hasPart" resource="#uri">
<h2 property="schema:name">Uniform Resource Identifier</h2>
<div datatype="rdf:HTML" property="schema:description">
<p class="note" role="note"><span>Note</span>: This specification does not describe the relationship between a Solid data pod <q>owner</q> and Web architecture’s <cite><a href="https://www.w3.org/TR/webarch/#uri-ownership">URI ownership</a></cite> [<cite><a class="bibref" href="#bib-webarch">WEBARCH</a></cite>].</p>

<section id="uri-slash-semantics" inlist="" rel="schema:hasPart" resource="#uri-slash-semantics">
<h3 property="schema:name">URI Slash Semantics</h3>
<div datatype="rdf:HTML" property="schema:description">
Expand Down Expand Up @@ -476,6 +480,14 @@ <h3 property="schema:name">Storage</h3>

<p>[<a href="https://github.com/solid/data-interoperability-panel/issues/10#issuecomment-598694029" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/153#issuecomment-624630022" rel="cito:citesAsSourceDocument">Source</a>]</p>

<p>Servers MUST keep track of at least one <a data-link-type="dfn" href="#owner" id="ref-for-owner">owner</a> of a storage in an implementation defined way.</p>

<p>When a server wants to advertise the owner of a storage, the server MUST include the <code>Link</code> header with <code>rel="http://www.w3.org/ns/solid/terms#owner"</code> targeting the URI of the owner in the response of HTTP <code>HEAD</code> or <code>GET</code> requests targeting the root container.</p>
csarven marked this conversation as resolved.
Show resolved Hide resolved
kjetilk marked this conversation as resolved.
Show resolved Hide resolved

<p class="note" role="note"><span>Note</span>: When a server supports multiple storages, there must be complete trust between its owners.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p class="note" role="note"><span>Note</span>: When a server supports multiple storages, there must be complete trust between its owners.</p>
<p class="note" role="note"><span>Note</span>: When a server supports multiple owners, there must be complete trust between its owners.</p>

?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think when a storage has multiple owners, trust between them is generally expected or well-understood. This is really about when a server supports multiple storages with different owners under the same host.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I fully understand the relationship/geometry between server, owner and storage (and Pod).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does it apply to https://solidcommunity.net/ ? One server supports multiple users but uses subdomain for each storage.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really about when a server supports multiple storages with different owners under the same host.

A Pod hosting scenario (per @elf-pavlik's point) would seem to fall under this category where a given server has multiple storages, with each having different owners, who may not know/trust each other.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?

The key word that I used was "host" but perhaps I should've used "scheme, host, and port" to be more accurate. This is boils down to origin (see RFC 6454). solidcommunity.net designates a unique "scheme, host, and port" with one "storage" to one "owner". It is currently a non-issue for solidcommunity.net as I understand it.

The main point remains in that if a service (like solidcommunity.net) were to allow multiple storages under the same "scheme, host, and port", then the owners of the storages (which could be the same owner) need to establish "trust" among themselves.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pod hosting isn't necessarily exclusive to sub-domains for segregation. Pod hosting scenarios can, and do, use path based segregation (e.g. https://host.example/pod-one, https://host.example/pod-two). In cases like those, the scheme, host, and port are the same, but still you have the likely scenario of different hosted pods owned by social agents that do know know and/or trust each other.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I responded to the original inquiry about subdomain based services and explained why that was a non-issue. Yes, multiple storages (on the same origin) with different owners has been possible for long time. It was never prohibited to begin with! (Heck, we've had different types of storages as well as workspaces... ) One of the reasons for the whole set of requirements around storage was acknowledging that reality (see PR #208 and https://solidproject.org/TR/protocol#storage ).. making sure non-overlapping URI ((path) space are used, among other things.

Trivial to get a wholesale scheme-host-port blocked (rendering it useless) by a service because of one bad actor, and hard to isolate the bad actors in that system. Not to forget CORS considerations.

The note doesn't prohibit servers/services that possibility. Both the service provider and the owners of the storages should be aware of what it entails.

The point in the note still stands and relevant for any set up.


<p>[<a href="https://github.com/solid/specification/issues/67" rel="cito:citesAsSourceDocument">Source</a>][<a href=" https://github.com/solid/specification/issues/132" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/153" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/197" rel="cito:citesAsSourceDocument">Source</a>]</p>

<p>When using Web Access Control (<a href="#web-access-control">Web Access Control</a>):</p>

<p>The root container (<code>pim:Storage</code>) MUST have an ACL auxiliary resource directly associated to it. The associated ACL document MUST include an authorization policy with <code>acl:Control</code> access privilege.</p>
Expand Down