API for deleting accounts about solid-spec

[dmitrizagidulin]

Thanks @akuckartz !

[dmitrizagidulin]

As mentioned by @csarven on solid-spec/68 - API to download/export account data:

The Export Account functionality should be brought to the user's attention when they start the process to delete their account. Emphasize on the point that "once you delete your account, you will lose this and this and this.. and will never get it back. We don't have archives..."

[nicola]

Thanks @akuckartz. I had this conversation several times, I will write down notes and questions I took:

• Should DELETE /folder/ remove all the files inside the folder (so a rm -r) ?
  • if YES - delete the LDP way:
    • pro: it would be enough to send DELETE / (which basically makes the account un-available from that point on)
    • cons: figure out a way to handle email confirmation, for example
  • if NO - delete via the API, should be about /accounts/delete (in ldnode is /accounts/new)
    • cons: less LDP/Solid-ish
    • pro: it would be nice to handle extra things (a confirmation email for example?)
    • cons: every service will implement their own apis..

[dmitrizagidulin]

@nicola - I'm not sure I understand the distinction.

Doing an HTTP DELETE to a profile (https://some-user.databox.me/profile/) is both an LDP and an API-type way to delete an account. (The /accounts/delete method you mention is actually an anti-pattern in the REST API world).

The confirmation dialog (or via email) is unrelated to this question, and is just handled via the UI of whatever app is displaying the 'Delete Account' link.

So, for example, if you're talking about the Profile Editor app, the 'Delete Account' button would first display a confirmation dialog or page (explaining that the account will be un-reachable from that point on, linking to the Export button, and so on). And only after the user clicks 'Confirm' would the app actually send that HTTP DELETE call.

Does that make sense? (The distinction between what the API should be versus what sort of confirmations and explanation the UI should handle?)

[nicola]

These are old notes, but let me answer your questions:

• HTTP DELETE to a profile as you mentioned https://some-user.databox.me/profile/ would remove the folder profile not the domain https://some-user.databox.me/, in other words, it would create unusable space, but would not delete all the data of the user (which I assume we want to achieve)
• With "API", I meant API endpoints that are not LDP. There are already some API endpoints that are not LDP. To create an account, in fact, both gold and ldnode implement their own endpoints (beyond LDP/Solid). To give you an example POST https://databox.me/,system/newAccount would create a new https://youraccount.databox.me. So, the point in which I mention delete via an API, I was considering having something on those lines POST https://databox.me/,system/newAccount or similar.
• I consider the UI solution to "confirm the action" too soft, for such strong effect. To give you an example, a badly coded app - which I trust - could just do a "DELETE /" and my online identity disappears - instead, if we can control such operations, then I would not be able to "DELETE /" since further action must be taken. Of course the UI can also handle this, but I am not sure this should be solely handled by the UI. This is a sort of 2-factor for account deletion. (This extra handling of deletion - e.g. email confirmation - should be up to the implementor, not necessarily defined in the spec, but the non-LDP API makes it easier than DELETE, since the latter is expected to be atomic by the user)

Let me know if you have further questions!

[dmitrizagidulin]

Ah, ok, I see what you're saying. In that case, yeah, I agree, it should be done via a non-LDP API endpoint. Something like DELETE https://databox.me/accounts/youraccount.
(Incidentally, I'd loove to see the new user account creation API endpoint to be changed to something more recognizeable to REST API users, something like POST https://databox.me/accounts/. Since, again, including the verb (newAccount) in the URL is an anti-pattern.)

As for the UI-only confirmation being too soft for the drastic effect, I think I understand.

How about -- issuing a DELETE https://databox.me/accounts/youraccount would result in a response of 201 Accepted or 204 No Content, with a response body containing a message to the effect of "A delete confirmation link has been sent to your email."

A one-time token would be generated, and sent in an email. Something like:

You have requested to delete your account on https://databox.me. If you have not initiated this action,
please disregard.

To confirm the deletion of your account, please visit:

https://databox.me/accounts/youraccount/confirm-delete?token=123456

Visiting that page from the email would show confirmation text and explanation of the effects, link to the Export button, and finally display a Confirm Delete button. Which, when pressed, would issue a POST https://databox.me/accounts/youraccount/confirm-delete?token=123456, which would finally delete the account (if the token was still valid, etc).

And so, the 2-factor auth part would be handled via email.

Would that work?

[nicola]

If we are talking about a non-LDP endpoint, yes. If we are talking about an LDP endpoint (which is what I would like to have if we overcome this problem), then I don't think so, since once you DELETE, the content is expected to return a 404 on GET. Maybe @deiu has more insights on this.

[dmitrizagidulin]

To expand on the non-LDP endpoint 2-factor via email deletion process (I hit submit on that previous comment too soon):

How about -- issuing a DELETE https://databox.me/accounts/youraccount would result in a response of 201 Accepted or 204 No Content, with a response body containing a message to the effect of "A delete confirmation link has been sent to your email."

A one-time token would be generated, and sent in an email. Something like:

You have requested to delete your account on https://databox.me. If you have not initiated this action,
please disregard.

To confirm the deletion of your account, please visit:

https://databox.me/accounts/youraccount/confirm-delete?token=123456

Visiting that page from the email would show confirmation text and explanation of the effects, link to the Export button, and finally display a Confirm Delete button. Which, when pressed, would issue a POST https://databox.me/accounts/youraccount/confirm-delete?token=123456, which would finally delete the account (if the token was still valid, etc).

And so, the 2-factor auth part would be handled via email.

Would that work?

[dmitrizagidulin]

If we are talking about an LDP endpoint (which is what I would like to have if we overcome this problem)

You're essentially talking about special-case handling of certain LDP endpoints. By either attaching some post-commit-hook like functionality to those endpoints, or having a Solid server keep a list of "magic" LDP endpoints, and handling them differently (such as only deleting them via a 2-factor auth step). Right?

[nicola]

Yes (if we agree that the set of APIs of the user are handled in a non-LDP way - which I would like to avoid, otherwise we are just proving that we still need non-LDP apis.. - maybe using capabilities in a very similar way you are proposing)

However, if we proceed with non-LDP APIs, we can't force this exact implementation in the spec. It is up to the implementor to choose this way with tokens or other valid alternatives.

[dmitrizagidulin]

However, if we proceed with non-LDP APIs, we can't force this exact implementation in the spec. It is up to the implementor to choose this way with tokens or other valid alternatives.

While we can't force exact implementation in the spec (although - why not? The Solid spec is still in progress, even if the LDP spec is finished), we can certainly give recommendations. Isn't that what the Solid project is about? Recommendations to server implementors regarding API endpoints etc?

[nicola]

@dmitrizagidulin that could be either done with a sort of post-commit-hook (you can already do this in ldnode). It depends what you mean by Magic endpoints. I don't want a magic handling of DELETE /, I want to be able to specify in the ACL file, who has the capability of doing so, and in what way.

The token mechanism, for example could be implemented with a finer grain ACL.

[dmitrizagidulin]

@nicola - tell me more about post commit hook? (is there links?)

As for specifying in an ACL file - that sounds promising. What would that look like?

[nicola]

I see Solid not as a set of "recommendations" but as a set of MUST and SHOULD :P
We should be as flexible and avoid this particular implementation as a "must".

post-commit-hook are just middlewares in Express routes, nothing fancy

var ldnode = require('ldnode')
var express = require('express')
var app = express()
app.use('/', ldnode(opts))
app.delete('/*', myMiddleWare)

[dmitrizagidulin]

As mentioned in our off-line gitter chat, I agree with you, in terms of being careful not to over-specify the API. In this issue, we're mostly talking about "how should we implement this initially in Gold and LDNode". :)

[dmitrizagidulin]

Moving to solid/solid#14 as a result of the solid project workflow discussion. Closing.