Delete WebID, Pod, and Account

[renyuneyun]

Feature description

A mechanism (or a series of mechanisms) to delete either a WebID, Pod, or an account. This becomes particularly useful since one account can create multiple WebIDs and Pods, but may want to free up some of them at a certain point.

This has been repeated mentioned in the past (#1139, #1655), but not implemented.

Deleting an account may be more complicated, so the route would likely be:

• [x] Support deleting a WebID
  • [ ] Optionally checking if any Pod is affiliated with it (on current site)
    • [ ] Optionally forcing deleting the WebID
• [ ] Support deleting a Pod
  • [ ] Optionally checking if any WebID is hosted inside the Pod (on current site)
    • [ ] Optionally forcing deleting them together
• [ ] Support deleting an account
  • [ ] Necessarily deleting all WebIDs and Pods associated with it

[joachimvh]

The main difficulty is probably deleting a pod, as you need to recursively delete all resources.

[elf-pavlik]

There are security implications if recycling or URI spaces (including WebIDs) are allowed. IMO the safest way is to allow deletion by creating a tombstone (could be internal) and not allowing someone else to take control over URI space that was previusly used by another person/organization.

[TallTed]

Such security implications can be substantially decreased if not eliminated by liberal use of PKEY signatures and related crypto application.

Permanent tombstones such as I think you are suggesting raise the spectre of ID squatting, especially when setting up on a prestigious WebID (via Pod) provider. There's only an expense once, and then you "own" the terminus (the "local portion") of that WebID everywhere, and only have to keep paying the rent to one provider.

In my experience with service providers who include some form of local username/identifier, deleting one's account gets a limited time window in which that identifier may be reclaimed (which prevents others from taking it for forward use), after which a new user may claim that username. Typically, the user profile includes something about when the account was "created" which is either when the original user created their account, or is when the new user took it over. This combines with various other details to protect people who may have historically interacted with the original user from believing that the new user is the same human who once possessed that username/identifier.

Remember that DNS registration, the next level up for WebID vulnerability/protection, only protects a domain name for a limited time.

[renyuneyun]

...Tombstone...

...the user profile includes something about when the account was "created" which is either when the original user created their account, or is when the new user took it over...

...only protects a domain name for a limited time.

I think that's quite valuable discussion and concepts about implications of account identifier handing over, either site-wise consequentially, or DNS-wise consequentially. Before switching to a permanent ID system (if LWS wants to do that), there is no perfect way for Solid to protect against that.

It occurs to me that there are the following ways of "handling" this:

Prevention method	Avoids local-taking-over	Avoids DNS-taking-over	Protocol changes required	Other comments
No	No	No	No
Tombstone	Yes	No	No
Account timestamp	Yes	No	Report account creation time + Record account creation time from every other user
Account timestamp + DNS timestamp	Yes	Yes	Report+Record account creation time + DNS update time verification (through SOA?)	Relying on DNS mechanisms
Account deletion message	Yes	Yes	A new standard message + Everyone to register for interest of receiving this message	Server needs to handle such messages in a routine
Permanent IDs	Yes	Yes	Everything of identity on Solid	WebID system won't work

But, for this FR specifically, this complexity does not have to be perfectly handled. I would consider:

1. This problem to be moved to Solid CG or LWS WG for discussion
2. To show a warning in the "deletion" function of CSS for such potential implications, but allow the action
   1. Maybe support an optional tombstone-like mechanism to mark this name as no longer valid; it does not have to be properly modelled such as having well-defined structural information explaining the tombstone -- an internal mechanism should be fine
   2. This should be optional because there are legitimate cases where this may be expected. For example, if I want to transfer the control of a WebID to another account. A better way is to directly support this, but currently it's not possible, AFAIK.

[elf-pavlik]

Such security implications can be substantially decreased if not eliminated by liberal use of PKEY signatures and related crypto application. [...] Remember that DNS registration, the next level up for WebID vulnerability/protection, only protects a domain name for a limited time.

I don't want to dive too deep in this conversation, especially that it is not specific to CSS. I don't see an average person capable of managing their private keys locally. Solid-OIDC relies on digital signatures but they are handled by the OP/IdP which is a hosted service. Of course this situation will be changing over time, PCs and even more smart mobile devices, and smart cards are relatively new inventions.

Acknowledging that one can loose control over a domain name, I still see it as middle way approach that should be rather accessbile for people who I would hope will start adopting Solid over the next decade. I could even imagine that that would be the only reliable way of getting a vanity WebID and URI space in general. If providers only have random generated handles and allow bringing your own domain the shouldn't be issue with squatting user names.

This problem to be moved to Solid CG or LWS WG for discussion

👍

I think the table and bullet points are very usefull, I'll wait with responding until we decide what is the best venua for the deeper dive.