Should the server always advertise the owner link relation?

[kjetilk]

Another outstanding issue from #264 was whether the link relation should always be advertised by the server.

This discussion includes whether the owner can be anonymous, and if so, what is the nature of anonymity with respect to WebIDs.

[kjetilk]

To further state my opinion, I note that the same URI https://example.org/card#me can directly identify a physical person, it can be a pseudonym or, it can link to nothing, and thus, it might be possible to argue it is anonymous.

The URI itself may give away that it identifies a physical person, https://example.org/kjernsmo#kjetil wouldn't leave much doubt, but for the most part, the real test is what it yields when it is dereferenced. It is also not much doubt if the response contains more personally identifiable information.

For pseudonyms, one must at the very least assure that the neither the URI nor any of the responses that may be obtained by dereferencing any following resources can cause re-identification. To really maintain pseudonymity, then you actually need to assure that the re-identification cannot occur by using this information in conjunction with any information from the Web. I'd say that's pretty hard...

If the actual requirement is anonymity, then clearly, then if there is a dereferenceable URI, the care that must be taken to ensure anonymity is probably even harder. Just dereferencing a URI can lead to data being in some server log somewhere.

I'd therefore argue that it doesn't make sense in Solid to talk about URIs for anonymous things, if an identifier exists, it is at least a pseudonym, with the security practices and legal requirements that follows (GDPR Recital 26 makes clear that GDPR applies to pseudonyms but not anonymized data).

This leads me to that we should not require the owner link relation to be advertised. If the owner requires anonymity, the way it is achieved is by not advertising the owner relation.

It is unclear to me what the argument for this feature is. If it is to allow some data to be found for the owner in all situations, then I think that it carries too much risk for re-identification. I propose that in this context, any deferenceable resource is a pseudonym.

[justinwb]

I propose that in this context, any deferenceable resource is a pseudonym.

Generally I am in agreement with this - if a server would always advertise an owner link relation with no other limiting factors.

That said, I'd like to respond to the primary question - Should the server always advertise the owner link relation? I think the pod owner should have the ability to choose.

One way to enact this choice would be to use a mechanism that we already have readily available; authorization. We could then say that the server always advertises the owner link relation, but the agent making the request must have been granted read access to the pod root to receive it. The owner would have the ability to pick and choose who can discover the owner identity URI, which could in turn be psuedonymous or not (again - the owner's choice).

I'm in full support of having an owner for a given pod, and advertising it on requests to the pod root. However, given the possibility for inadvertent information disclosure (e.g. someone puts PII in a webid that is advertised publicly), I think that we should make it protected by default, so that owners have a choice in the matter.

[d-a-v-i--]

Authorization would inherently be in conflict with concepts of anonymity and thus very complicated to implement. The more elegant solution could be to allow an owner link to be whatever someone wants (random or meaningless, not missing). A lack of integrity requirement preserves confidentiality better than forcing identification through authorization, while trying to create anonymity.

[kjetilk]

The more elegant solution could be to allow an owner link to be whatever someone wants (random or meaningless, not missing).

Right, and we could even provide a URI for it, like https://id.solidproject.org/anonymous#user which any user could use for anonymity. However, I'd like to understand the use case for such a thing. For the most part, we want URIs to give people something when they GET it, in the case of an owner possibly a way for them to ask for permission to do something, file a complaint, etc. If the URI doesn't resolve to anything they can use for that, I don't see the point, but I'd be interested in use cases.

[justinwb]

A lack of integrity requirement preserves confidentiality better than forcing identification through authorization, while trying to create anonymity.

I'm not sure that the intention of advertising the owner is to create anonymity . The need for anonymity was only raised as a new problem created by advertising the owner to everyone.

For the most part, we want URIs to give people something when they GET it, in the case of an owner possibly a way for them to ask for permission to do something, file a complaint, etc. If the URI doesn't resolve to anything they can use for that, I don't see the point

Agree - the utility of having the owner established and available can be useful - but I'm not sure how useful that would be if the information was inaccessible.

but I'd be interested in use cases.

+1 on use cases.

[kjetilk]

So, rereading @csarven and @acoburn 's comment, then yes, I see that a case could be made for that the simplest solution might be to require the owner relation to be advertised and leave to the implementation to determine what that URI might be, and to ensure that no identifying information can be gleaned from it.

If we allow this, then people could say in the response that it is an anonymous user, and so indicate to clients why there aren't anything. Continuing on the idea to give a URI for a generic anonymous user could say something like

<https://id.solidproject.org/anonymous#user> a solid:AnonymousAgent .

If we don't require that relation, then we cut off that opportunity. So, I'm sliding towards a 👍 on this as a requirement anyway.

[justinwb]

I see that a case could be made for that the simplest solution might be to require the owner relation to be advertised and leave to the implementation to determine what that URI might be, and to ensure that no identifying information can be gleaned from it.

If the utility of advertising an owner relation only exists if the owner opts out of anonymity, we may be eliminating useful scenarios where the owner wants only a limited group to know they are the owner.

• What features won't work if someone chooses to use an anonymous URI?
• Will people end up giving away a bit of privacy in exchange for a feature?
• Do we have to leave them with that choice? How many users are prepared to understand the tradeoff?
• Is there another avenue beyond this advertisement in the Link header to discover the owner? If so, it may address the previous concerns.

[kjetilk]

Good questions.

I'm not sure which features will not work if they choose an anonymous URI, but I'll try an answer to the last question:

Is there another avenue beyond this advertisement in the Link header to discover the owner? If so, it may address the previous concerns.

I imagine that people will put a triple in the body of a representation of some resource, where it would be subject to access control. Possibly in the root container or something.

[justinwb]

I imagine that people will put a triple in the body of a representation of some resource, where it would be subject to access control. Possibly in the root container or something.

I think it's a sensible approach. If the owner was advertised based on that stored value, who the owner was would still be something that was accessible for certain workflows, subject to regular authorization, while at the same time publicly advertising an anonymous identity. I think it makes sense to have that as a server-managed value, so that it would only be changed through administrative interaction (i.e. facilitating an account transfer).

[kjetilk]

Yeah, and sometimes I feel that we may be over-using the Link header a bit... Back in the day, it was largely up to the application programmer to supply the body of the HTTP message, while the headers were more the domain of the framework programmer, and therefore the logic behind the headers where more expensive to change. I suppose framework developers of Solid servers are inclined to allow simple access to add Link headers, but still, there is a middle ground where access control applies and there are server managed triples, and it seems to me that we should be better at exploiting that.

[csarven]

Let me first say that I'm not an expert on privacy by/or data minimization, so take below with a grain of salt. I also do not think that anything in this issue should be generalised to the Solid ecosystem - especially when the discussion includes less than five people with zeroone (mine) implementation. The general topic would deserve its own panel with experts.

---

The requirement in #264 is essentially:

Link: <URI-Reference>; rel="http://www.w3.org/ns/solid/terms#owner"

Full stop.

The Protocol is not defining a URI Template for the URI-Reference. Why? Simply so that wherever, whenever, however.. the Protocol is used, it can be applied and used in a way that accommodates the needs of the environment and users. Neither is the Protocol implying anything beyond what a URI in context of the owner entails - we don't have a Solid URI scheme either.

There are ample reasons why the owner URI can use any pattern eg. http://example.org/{uuid}#i, http://example.org/TON-618#i... https://id.solidproject.org/anonymous#user.. https://csarven.ca/#i.

Aside: https://id.solidproject.org/anonymous#user is less anonymous than http://example.org/{uuid}#i simply because the former can be easily (or uniquely characterisable) identifiable in a set of identifiers. So, it is actually counter to what's desired. Neither is it the case that it is "anonymous" because it says so in the identifier or if it is claimed to be AnonymousAgent. Asideception: an anonymous agent may want to reveal their identity at a later date.

Aside: My original point about owner being linkable was to enable consistent discovery. I contrasted it to owner being unlinkable ie. server not advertising the link relation. Linking does not eliminate anonymity. Varying degrees of anonymity can still be achieved ie. the identifier doesn't need to be distinguishable from a set of identifiers, neither is there any expectation or association needs to be drawn to any identity or its attributes.

This is where Variability in Specifications plays an important role. The Protocol defines as much as it needs to and leaves sufficient space for implementations to vary. It can be revisited at a later date eg. based on implementation experience as well as how those implementations work out in real life - being informed by observable.. "utility".

The question is not "what's the use case for linking to the owner without a representation?" The use case is owner linkability. The Protocol states the requirements for that. Allowing representation or no-representation is a design decision (variability).

I think much of what's discussed here is most suitable for a Best Practices and Guidelines document - considerations that implementations should take into account. If there are stronger reasons to have orthogonal specs covering different aspects of data minimization in Solid, we can look into that - via dedicated panel perhaps.

As for people wondering about whether there is an alternative way to discovering the owner information besides the link relation... I'm not sure if that's a genuine question at this point in time because one doesn't know or can't think of any possibilities... or forgot existing issues that covers the general topic eg. resource for server/storage (meta)data. Immutable and server-controlled information about the resource eg. creator, date issued/created/modified is in the same category or should be considered at the same time.