Pod administration


#1

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.


#2

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 :

  1. The actual access control and full extended profile
  2. Some intermediate position with only part of the card profile
  3. 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.