data-interoperability-panel
data-interoperability-panel copied to clipboard
solid
Discovery of account management
The various implementations might differ in how they allow users to manage their accounts. Should the data that describes these options be standardized somehow, so that various clients can present them to the users?
Example: Alice wants to delete her account on https://alice.solid.community. How does she know that to delete her account she must visit https://alice.solid.community/account/delete ?
Does she have to go through the account provider's UI, should there be standardized APIs, or at least a data model that describes the various possibilities for account management?
Should the data that describes these options be standardized somehow, so that various clients can present them to the users?
Yes, IMHO. Was also @timbl's suggestion.
Even created a spec document for that already: https://github.com/solid/specification/blob/master/pod-management/index.bs
should there be standardized APIs, or at least a data model
Yes.
As far as I'm concerned:
- the LDP API
- with specific data models
This would be a case where I would say that we agree on exact ontologies and spec them. (As opposed to data guidance for data that is inside of the pod.)
If this is outside the scope of this Panel, let me know.
Definitely in scope, IMHO.
I understand this would only apply to Identity Provider and not regular a Resource Server providing storage?
Can apply to both. Storage accounts are accounts too, with or without identity.
The various implementations might differ in how they allow users to manage their accounts. Should the data that describes these options be standardized somehow, so that various clients can present them to the users?
@megoth I really like this - management of the places where i keep my things should be interoperable and not subject to the decisions made by specific implementations.
This would be a case where I would say that we agree on exact ontologies and spec them. (As opposed to data guidance for data that is inside of the pod.)
Agree +shapes.
Even created a spec document for that already: https://github.com/solid/specification/blob/master/pod-management/index.bs
This seems like it would justify a project with an aim to create a candidate proposal to the specification on pod management standards.
@megoth this was discussed in the live meeting of the panel today and there was consensus that we should go ahead and get a project formed around this. Thanks for raising this!
I believe this issue is sufficient record as far as recorded votes for this to move forward, but lets agree on the project aim / scope so we can initiate it properly...
The aim of this effort would be to produce a candidate proposal to the Solid Specification that outlines the mechanisms and data models needed for a consistent and interoperable management of Solid data pods.
Some considerations raised in panel meeting 2:
- Important to disambiguate Identity Provider and Resource Server.
- Operations on the Resource Server (data pod)
- Create an account
- Delete an account
- Deactivate an account
- Migrate an account (redirect)
- Recover an account
- Parental control over account
- Important to disambiguate Identity Provider and Resource Server.
The same API might be used for both though.
(e.g., providesWebId might just be a predicate)
- Operations on the Resource Server (data pod)
Here, we will need to be careful with terminology. It's not the data pod, but the level above it.
For simplicity, we could just call them "account management operations".
Parental control over account
I would leave this out of the initial scope, this is much more complex than the rest.
Another disambiguation I think we need to do is between how the Pod Provider manages accounts on their system, and how the user manages their own account.
Perhaps we should clearly scope this issue to the latter? Supposedly, the former will use methods from the former to do work, but it is a lot more work, and also difficult policy issues associated with it.
Parental control over account
I would leave this out of the initial scope, this is much more complex than the rest.
Yeah, the full scope of Parental Control is really hard. Initially, it could be thought of us just about setting some acl:Controls when creating a Pod, and so, a way to write the ACLs that initializes the Pod could suffice, but it is more a Pod Provider problem than a user account problem. So, as per the above, perhaps we should set the scope of this project to be user account only, and Parental Control would be a part of a future Pod Provider management project?