Add notion of "owner" and requirements #264

csarven · 2021-05-19T13:18:20Z

Hello Reviewers,

In response to the following (and possibly other) issues on the notion of "owner":

If describing the relationship between Solid data pod / storage "owner" and AWWW's "URI ownership" is required, it can be done in another PR.

On merge of this PR, a follow-up PR will be made to the https://github.com/solid/vocab/ repository requesting to add and define the term "owner" in the Solid Terms vocabulary: http://www.w3.org/ns/solid/terms#owner. Proposal (derived from http://www.w3.org/ns/auth/acl#owner ):

solid:owner
    a rdf:Property ;
    dc:issued "2021-05-19"^^xsd:date ;
    rdfs:comment "The person or other agent which owns the data storage. For example, the owner has implicit control of a data storage."@en ;
    rdfs:isDefinedBy <http://www.w3.org/ns/solid/terms#> ;
    rdfs:range foaf:Agent ;
    rdfs:label "owner"@en .

timbl

looks good to me

bblfish · 2021-05-19T13:56:40Z

The domain of the relation is not defined explicit. I guess it is a Pod, or would it be a ldp:Container?

csarven · 2021-05-19T14:23:14Z

Intentionally undefined for the time being. Implementation feedback would help. In the Protocol, servers exposing the storage resource (root container) also has a rel="type" link relation http://www.w3.org/ns/pim/space#Storage.

If we lean towards pim/space, it could also be pim:ControlledStorage. The property could alternatively go under pim/space eg. pim:owner.

kidehen

Intentionally undefined for the time being. Implementation feedback would help. In the Protocol, servers exposing the storage resource (root container) also has a rel="type" link relation http://www.w3.org/ns/pim/space#Storage.

If we lean towards pim/space, it could also be pim:ControlledStorage. The property could alternatively go under pim/space eg. pim:owner.

You should include the rdf:domain for clarity.
As I see it, the rdf:domain would be rdfs:Resource if want to be broad.

solid:owner
    a rdf:Property ;
    dc:issued "2021-05-19"^^xsd:date ;
    rdfs:comment "The person or other agent which owns the data storage. For example, the owner has implicit control of a data storage."@en ;
    rdfs:isDefinedBy <http://www.w3.org/ns/solid/terms#> ;
    ## Property Domain Addition
    rdfs:domain rdfs:Resource ;
    rdfs:range foaf:Agent ;
    rdfs:label "owner"@en .

kidehen · 2021-05-19T14:58:40Z

Intentionally undefined for the time being. Implementation feedback would help. In the Protocol, servers exposing the storage resource (root container) also has a rel="type" link relation http://www.w3.org/ns/pim/space#Storage.

If we lean towards pim/space, it could also be pim:ControlledStorage. The property could alternatively go under pim/space eg. pim:owner.

You should include the rdf:domain for clarity.
As I see it, the rdf:domain would be rdfs:Resource if want to be broad.

solid:owner
    a rdf:Property ;
    dc:issued "2021-05-19"^^xsd:date ;
    rdfs:comment "The person or other agent which owns the data storage. For example, the owner has implicit control of a data storage."@en ;
    rdfs:isDefinedBy <http://www.w3.org/ns/solid/terms#> ;
    ## Property Domain Addition
    rdfs:domain rdfs:Resource ;
    rdfs:range foaf:Agent ;
    rdfs:label "owner"@en .

matthieubosquet · 2021-05-19T15:38:36Z

protocol.html

+
+                  <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>
+
+                  <p class="note" role="note"><span>Note</span>: When a server supports multiple storages, there must be complete trust between its owners.</p>


Suggested change

Note: When a server supports multiple storages, there must be complete trust between its owners.

Note: When a server supports multiple owners, there must be complete trust between its owners.

?

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.

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

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

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.

?

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.

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.

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.

protocol.html

csarven · 2021-05-19T16:23:08Z

@kidehen No objection to including rdfs:Resource but I don't think it is needed. Wouldn't that always be inferred?

protocol.html

RubenVerborgh · 2021-05-19T17:30:08Z

    rdfs:comment "The person or other agent which owns the data storage. For example, the owner has implicit control of a data storage."@en ;

The "for example" doesn't seem to work well.

bblfish · 2021-05-19T19:58:05Z

So if I understand correctly in N3 we have

# we first define the transitive closure of ldp:contains
:contains٭ owl:TransitiveProperty;
     rdfs:subPropertyOf ldp:contains .

# we then have the N3 rule
{ ?rootLdpc :owner ?agent } => {  
     [] acl:agent ?agent ;
        acl:mode acl:Control;
        acl:accessToClass [ a owl:Restriction;
              owl:onProperty [ owl:inverseOf :contains٭ ];
              owl:hasValue ?rootLdpc 
         ]
}

If it were a little clearer what the domain of the relation was (the domain-name perhaps?) one could adapt the definition.

kjetilk · 2021-05-20T10:14:48Z

Your proposal to define it in terms of pim:Storage is better, but still seems somewhat vague then. It leaves open whether we are identifying electronic devices via a hardware serial number, Hardware UUID, Provisioning UDID (info I find available for my computer) or with a domain. Are we interested in the ownership of the hardware, or in the topological position of the device on the internet? For the latter, it could be a MAC address or a domain name.

Alright, perhaps we should have a solid:Storage and tighten the definition appropriately?

I agree that we should have the domain in there as it very clearly binds the definition of an owner to the definition of a storage, which is very clearly specified in terms of the URI hierarchy in the protocol spec, which is again a rigorous definition AFAICS. It is therefore important to have a RDFS class that is equally strongly tied to the protocol's definition of storage. I can see that the pim:Storage definition can be interpreted rather broadly, so I say we tighten it.

protocol.html

justinwb · 2021-05-31T11:01:12Z

protocol.html

+
+                  <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>
+
+                  <p class="note" role="note"><span>Note</span>: When a server supports multiple storages, there must be complete trust between its owners.</p>


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.

csarven · 2021-05-31T12:30:05Z

@kidehen @bblfish @kjetilk :

The intended definition of solid:owner draws from acl:owner. It is broader in the sense that "there is a sense of right of control" over all data in a storage. Obviously no disagreement to make solid:owner more clear. Part of the reason why I left it vague was to work it out based on what's intended by the spec. The current rdfs:range foaf:Agent is intentional, so the term is definitely not about "agent owns/ownerOf thing".

We use the pim:storage property eg. agent has storage, where the range is defined to be an instance of pim:Storage. The arc from a storage to an agent is intended to be solid:owner. I think that's fine (ie. we can do rdfs:domain pim:Storage. Unless pim:Storage gets new subclasses (eg. for new devices/hardware..), I don't see what an equivalent like solid:Storage brings to the table.

@elf-pavlik

I borrowed/introduced "social entity" from AWWW's URI ownership. There are social expectations and processes. Possible to go from responsibility/accountability chain from data "ownership" to URI ownership.. domain name registration through IANA (another social entity). And as I've said at the beginning of this PR:

If describing the relationship between Solid data pod / storage "owner" and AWWW's "URI ownership" is required, it can be done in another PR.

AFAIK, "owner" in Solid is deemed to be a "social entity" of sorts, as opposed to a software agent. If there is existing discussion/work that incorporates non-living organisms under "owner", references would be great. (And to our future non-living organism overlords, I don't mean to discriminate, please go easy on us.)

kjetilk · 2021-05-31T14:28:08Z

I don't see what an equivalent like solid:Storage brings to the table.

Again, lets open a separate issue. I'd like to discuss tying it very explicitly to Solid's definition, which is rooted in its hierarchy, that's something that doesn't exist in the general case.

csarven · 2021-05-31T14:43:36Z

I'd like to discuss tying it very explicitly to Solid's definition, which is rooted in its hierarchy, that's something that doesn't exist in the general case.

Perhaps solid:Resource: #194 (comment)

kjetilk

I have opened #265 and #266 to continue the discussion of the exposure of the owner relation and the domain of the relation there.

And given that these issues can be resolved there, I approve this PR.

timbl

looks good to me this is important for existing servers.

csarven · 2021-06-04T11:20:27Z

Implemented owner discovery in https://github.com/csarven/mayktso

curl -I https://linkedresearch.org/ldn/tests/

link: <http://www.w3.org/ns/pim/space#Storage>; rel="type"
link: <https://csarven.ca/#i>; rel="http://www.w3.org/ns/solid/terms#owner", <https://example.org/a43a1874-c51e-11eb-a893-3fad0d2fdf12#i>; rel="http://www.w3.org/ns/solid/terms#owner"

justinwb

I support the notion of a storage owner, because it's valuable for interoperability and data sharing workflows (e.g. where data in a given storage is shared by a non-owner with access to do so, and whose data they are sharing needs to be communicated)
I support public advertisement because there are cases where a non-privileged agent should be able to know whose storage they're accessing.

It is important that public advertisement can be anonymous, and I believe that most pod owners will choose to do so. This may impact the viability of certain workflows where discovery of ownership is necessary. That needs to be addressed, but doesn't have to block this submission, as we now have a separate thread where this is being discussed (#266). Similarly, I've also created #267 to continue this thread.

csarven · 2021-06-16T10:59:22Z

Was waiting for additional feedback from implementers before merging..

Mayktso currently only implements the discovery bit as mentioned earlier: #264 (comment)

Noting here that CSS is in the process of implementing this feature: CommunitySolidServer/CommunitySolidServer#720 .

NSS has a PR for it: nodeSolidServer/node-solid-server#1604

Solid-NextCloud has shown interest in implementing: pdsinterop/solid-nextcloud#48

Will update this comment with more.. or others (/me friendly nudges @kidehen @gibsonf1 @acoburn @bblfish .. ) can show/link to their implementations in the comments

As for the solid:owner definition, here is an update based on earlier discussion that can be PR'd to solid/vocab - we can finalise the exact definition there, instead of here:

solid:owner
    a rdf:Property ;
    dc:issued "2021-05-19"^^xsd:date ;
    rdfs:comment "The a person or a social entity that is considered to have control, rights and responsibilities of a data storage."@en ;
    rdfs:isDefinedBy <http://www.w3.org/ns/solid/terms#> ; # alternative: <https://solidproject.org/TR/protocol> ;
    rdfs:domain ws:Storage ;
    rdfs:range foaf:Agent ;
    rdfs:label "owner"@en .

As agreed, we'll work out related/orthogonal issues (that were deemed to be non-blocking).

csarven added the doc: Protocol label May 19, 2021

csarven added this to the ~First Public Working Draft milestone May 19, 2021

csarven requested review from Vinnl, bblfish, michielbdejong, matthieubosquet, megoth, elf-pavlik, acoburn, kidehen, bourgeoa, joachimvh, KyraAssaad, VirginiaBalseiro, zenomt and a team May 19, 2021 13:18

timbl approved these changes May 19, 2021

View reviewed changes

kidehen suggested changes May 19, 2021

View reviewed changes

matthieubosquet reviewed May 19, 2021

View reviewed changes

protocol.html Show resolved Hide resolved

matthieubosquet reviewed May 19, 2021

View reviewed changes

protocol.html Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

RubenVerborgh reviewed May 19, 2021

View reviewed changes

protocol.html Outdated Show resolved Hide resolved

protocol.html Outdated Show resolved Hide resolved

csarven mentioned this pull request May 20, 2021

Track who is the pod owner and allow them always control access. nodeSolidServer/node-solid-server#1489

Closed

acoburn reviewed May 21, 2021

View reviewed changes

protocol.html Show resolved Hide resolved

kjetilk linked an issue May 25, 2021 that may be closed by this pull request

Should it be possible to find controller of storage via resources? #153

Closed

csarven added 2 commits May 26, 2021 15:10

Add notion of "owner" and requirements

53d4bd0

Revise owner definition and its use by server

e52176c

csarven force-pushed the feature/owner branch from 6ba032d to e52176c Compare May 26, 2021 13:12

justinwb reviewed May 31, 2021

View reviewed changes

This was referenced Jun 1, 2021

What is the domain of the solid:owner relation? #265

Open

Should the server always advertise the owner link relation? #266

Open

kjetilk approved these changes Jun 1, 2021

View reviewed changes

timbl approved these changes Jun 2, 2021

View reviewed changes

acoburn approved these changes Jun 4, 2021

View reviewed changes

justinwb mentioned this pull request Jun 4, 2021

Should there be trust between owners when a server supports multiple storages on the same origin #267

Closed

justinwb approved these changes Jun 4, 2021

View reviewed changes

bourgeoa approved these changes Jun 14, 2021

View reviewed changes

timbl merged commit 7ae9451 into main Jun 16, 2021

timbl deleted the feature/owner branch June 16, 2021 10:27

ylebre mentioned this pull request Jun 16, 2021

Add 'solid:owner' to the users storage pod and always allow the owner 'Control' pdsinterop/solid-nextcloud#48

Open

csarven mentioned this pull request Jun 17, 2021

Initial Editor’s Draft of the WAC specification solid/web-access-control-spec#83

Merged

bourgeoa mentioned this pull request Jul 14, 2021

There could be multiple owners nodeSolidServer/node-solid-server#1606

Closed

This was referenced Jul 26, 2021

Add owner to solid terms solid/vocab#52

Merged

ACP pod owner not defined solid/authorization-panel#171

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add notion of "owner" and requirements #264

Add notion of "owner" and requirements #264

csarven commented May 19, 2021 •

edited

Loading

timbl left a comment

bblfish commented May 19, 2021 •

edited

Loading

csarven commented May 19, 2021

kidehen left a comment •

edited

Loading

kidehen commented May 19, 2021 •

edited

Loading

matthieubosquet May 19, 2021

csarven May 19, 2021

matthieubosquet May 19, 2021

elf-pavlik May 26, 2021

justinwb May 31, 2021

csarven May 31, 2021

justinwb Jun 1, 2021

csarven Jun 7, 2021

csarven commented May 19, 2021

This comment has been minimized.

RubenVerborgh commented May 19, 2021

bblfish commented May 19, 2021

kjetilk commented May 20, 2021

justinwb May 31, 2021

csarven commented May 31, 2021

kjetilk commented May 31, 2021

csarven commented May 31, 2021

kjetilk left a comment

timbl left a comment

csarven commented Jun 4, 2021

justinwb left a comment

csarven commented Jun 16, 2021 •

edited

Loading


		<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>

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

Add notion of "owner" and requirements #264

Add notion of "owner" and requirements #264

Conversation

csarven commented May 19, 2021 • edited Loading

timbl left a comment

Choose a reason for hiding this comment

bblfish commented May 19, 2021 • edited Loading

csarven commented May 19, 2021

kidehen left a comment • edited Loading

Choose a reason for hiding this comment

kidehen commented May 19, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

csarven commented May 19, 2021

This comment has been minimized.

RubenVerborgh commented May 19, 2021

bblfish commented May 19, 2021

kjetilk commented May 20, 2021

Choose a reason for hiding this comment

csarven commented May 31, 2021

kjetilk commented May 31, 2021

csarven commented May 31, 2021

kjetilk left a comment

Choose a reason for hiding this comment

timbl left a comment

Choose a reason for hiding this comment

csarven commented Jun 4, 2021

justinwb left a comment

Choose a reason for hiding this comment

csarven commented Jun 16, 2021 • edited Loading

csarven commented May 19, 2021 •

edited

Loading

bblfish commented May 19, 2021 •

edited

Loading

kidehen left a comment •

edited

Loading

kidehen commented May 19, 2021 •

edited

Loading

csarven commented Jun 16, 2021 •

edited

Loading