On top of the ACL way which I feel not fully safe, there could be an account initial backup preferably outside of /root pod for example in .dB/accountsBackup.
The user can have access on the server page to an admin Pod page where with his credentials ( checked against the .dB/users/) he could have access to an API with :
. Rebuild of his lnltial profile card
. Pod delete,
. Edit Pod parameters (pod user name, password, security email, …
. Backup/reload extended profile
. Edit external WebID and associated parameters
…
The server page is then a Pod admin/creation page.
Actually the external WebID is directly using the full extended profile page (card and preferences /settings/prefs.ttl /publicTypeIndex /privateTypeIndex) of the external WebID.
It looks like an extended storage.
There are other use case that could be accessed with an account parameter :
- The actual access control and full extended profile
- Some intermediate position with only part of the card profile
- Only access control
Personally I don’t see a real use case in 1 and 2.
Others can have use case or just sake of compatibility for case 1.
Case 3 give the simplicity of multy-pod management by the same person and ease of transfert to an other person, but also to use non Solid WebID’s and a special WebiD address book.