Podiverse

1

Forgive me in case I start a topic based on my lack of knowledge of how SOLID Project is supposed to work.

What I am signed up to is everyone being able to take control of everything to do with their digital identity. Most people have trusted devices on which they run applications. These devices store usernames and passwords for web based applications and cloud based storage. The likes of Facebook, X and others hold our data and process it to serve their own business model.

Is the future of the SOLID Project (SP) to provide alternatives to these applications based on its principles or to provide a means whereby users reclaim their data and then make it available back to these applications subject to the rules that SP enshrines, which would have to be robust and fair including where required non-repudiation and version control? Of course both can use the same model. Social media applications would have to defer rendering posts to the client side application to ensure that data is subject to the owner’s access controls.

In my mind the forms (including social media posts) I fill in are mechanisms for sharing my personal data. I would expect certain bits of personal data to be automatically extracted. I’d also expect that data such as my date of birth not to be unnecessarily available and access directly to it to be granted only to licensed agencies. Others might be able to get answers to questions such as ‘am I an adult?’.

Fundamental to the protection of my data is its encryption. My devices and the applications they run are the only places where it should be rendered in unencrypted form. My storage is where it is stored in encrypted form within an appropriate container. If quoting of rendered data is permitted by me, then this acts only to create an embedded link - this should be subject to access controls set by me on the quoted data and those quoting etc possibly requiring some excluded entities to request access. All applications should be able construct objects representing some of the data they hold which can be embedded anywhere else just like quoting.

Just think how this forum might be implemented using SP! As things stand these ideas could easily be plagiarised. How should copyright be protected? Well the SP needs to be able to act as a copyright library as well. Maybe the owner needs to be able to register copyright.

Thinking further about this, it would make sense if users have one Pod provider which establishes their identity. Through this the user identifies his devices. The devices then define the allowable Apps. Now the fun starts here because essentially the Apps are a kind of slave Pod with a client and server side, which can access the users most sensitive data in order to locate their Application data held on the slave server databases. The key to all this is to make everything secure and prevent Trojan horse attacks.

Years ago I knew @timbl. We had interesting chats. Right now I am just as interested in High Energy Physics and Cosmology because that was the academic world I gave up. I’d be interested in your thoughts and those of @acoburn .

Phil

2

I am somewhat new here but I will do the best I can to address some of your points.

It is true the SOLID project is to allow users to gain possession of their data, but the inclusion of RDF-style formats for use in navigation and storage is to allow the easy injection of context into data, and also allow for users to swap pod providers, identity providers, and other digital agent-based services easily in the long-term. This is vital as data without context is just a string, number, or other type.

It is supposed to be an alternative/competitor/replacement to existing structures where large providers hold, own, and sell all of your data. Controlling where your data goes, where it is stored, and who has access improves users’ privacy and choices regarding personal data storage and use.

As far as social media applications goes, there would be some changes. Determining where posts are stored is a challenge - how do you verify if the post has been changed or deleted? But also would provide some benefits. I can add other URIs that are blogs to follow, and could also remove them as I see fit, and as of now there is no algorithm to show you things you’d like to see - it would be relatively organic. You could also potentially have a co-owned pod for multiple agents who post data to the same URI, and users could follow that - though that brings challenges about who handles the ability to read from and controls that feed.

As far as answering questions of claims about an adult, I would recommend reading this specification. It will give you a better idea of how that question should best be answered currently.

Encryption is important and SOLID servers are working towards it - but that would be better asked to the maintainers of the Node SOLID Server, the Community SOLID Server, the PHP SOLID Server, and Inrupt’s team.

As far as copyright goes and data being plagiarised, that is an existing issue as well, and I have seen nothing so far to address it, so I hope more informed people chime in. But that is currently no different where a large company right now takes my data and sells it, even though I am the one who produced it.

For the Pod provider establishing identity, there is no need currently. The Identity Provider is the one who handles your WebID profile, and other services authenticate against this. Adding more data to the webID is possible, such as links to keypairs, tokens, and certificates for approved applications has received some attention.

If I haven’t addressed enough, or am incorrect, please read this thread right here. It is full of information regarding the future of SOLID applications, as well as some facts and opinions about the current state and where the SOLID specification should be going.

1 Like
3

Thanks for your reply. It seems to me that much has to be decided and there is no overview of the vision. I can only grasp the theories of modern physics with concepts. Maths turns me off until the basics are clear. Lots of detailed documents.

I welcome the initiative as the web has many serious issues which allow criminal activity. A relaunch is needed and this time it needs to be right. It’s not just about encrypting data in transmission, but offering total privacy even on storage servers.

For example, if I’m to feel confident I think it best to have more than access controls, but also encryption. If someone gets to read my data I (a Pod on which some data is stored will provide it and a (public key) to decrypt it and encrypt anything returned. Every type of application needs clear scenarios to explain typically who does what. Something like Facebook has posts and comments and because of overlapping friend groups it is easy for information to leek outside your own group. Now I’d say that at minimum only my friends see my comments on a friends post rather than all the friend’s friends. Now awareness of other comments is ok, but not the if and content. Now I suppose FB would say their way encourages friendships to grow, but I prefer to have choices. Now I do like FB groups so like this forum clearly a different security policy should be invoked.

Security in all its forms needs to be specified up front. I was involved in a government project that required the highest level of trust 35 years ago. It was really too ambitious and looked for formal proof of a security propertywhich we did demonstrate competence in using Abrial’s B tool. The concerns were very indirect leakage. Ancestry is poor at concealing information in any private tree.

So lots of high level security specifications needed including key management.

I tried the Free personal Pod provider service available from a numbers of providers. A bit disappointed it doesn’t give a clearer idea of how things are intended to work. I did fail to make timbl a friend even though I gave his ID thingy permission to update my profile. It seemed a odd very dubious way to do it. However I guess if your ID is your shop window to the world things need to be a bit different, but consent seems important (with FB it asks at least). There didn’t seem any way of deciding who could see DoB. It would be good to see specs for this as part of specify the Security. I feel more comfortable with a person to person mechanism like swapping phone numbers. Again all possible scenarios need to be set out with options to gradually move to greater levels of trust.

I read a bit of the thread you linked to in your reply. Thanks again. I think I vote to a truly decentralised model. I can appreciate that I may have to pay for the privilege. I certainly want my data to be safe from loss and shared I accordance with my access controls. A big worry must be getting fast enough responses when everyone takes ownership of their data and the rules for access to it. I can only say reading speed sets a limit.

If anyone knows where the high documents are I would be very grateful.

Phil

4

I took DoB as an interesting piece of personal ‘data’. Yes, the idea of verified credentials is important. My WebID is totally unverified. It’s worth exploring the properties of DoB in my conception of the Podiverse:

  • It is a piece of data that is unique (but not by its numerical value) in the Podiverse.
  • It is an attribute of a person’s WebID, so it is bound to the WebID.
  • If it is verified then it is bound to verified credentials through the WebID.
  • Access to it is subject to data protection laws, as are other attributes of WebID.
  • If I share my WebID with an employer for instance their employment Pod Application would be able to produce forms containing my DoB where necessary. Unlike current forms and paper, the form would not be printable. It would contain an electronic representation linking to my WebID. If the person viewing the form had the privilege to view DoB then they would see it. Otherwise, it would either display as blank or whatever their privilege allowed (say over 18). On the other hand if I sent it to a friend, then they would see what I allowed them to see (say over 18 or birthday).
  • If someone is a ‘friend’ and thus attributes of my WebID are shared I should be able to control what access they have. It could be as simple as read access, but it could be limited to certain properties such as over 18, minor, birthday (day and month) etc.
  • Other types of relationships are needed which define responsibilities, such as a social media platform’s responsibility to protect children from harmful content. Different privileges apply to different roles within an organisation.
  • Not all the attributes of my WebID should be available just because my DoB is held. If I go by an alias that requires some entity to check my DoB to ensure I am not a minor then clearly my legal name is private. However if the police need to contact me they have the privilege to get fuller access to my WebID.

I could continue brainstorming this one attribute until all aspects are understood. There are other pieces of personal data that have some of the same behaviours.

It’s rather important that we don’t just see data as how it is represented (Unix date time converted to a calendar date in U.K. format etc.)

Phil

5

As far as friend vs employer vs others being able to extract information about the DoB field, one are that addresses this could be selective disclosure. I won’t cover it since the link does a better job of explaining the concept.

However this proposal could be overkill in some simpler scenarios where there is no burden or penalty for failing-to-prove, and for those cases there is the extendedProfile documents and description. This attaches more information about your profile that you may not want immediately read-able within your WebID. The case I have found for it is to use it to store links to directories that contain partial information with whichever agent needs a specific document. This can get messy, so VC is harder to implement, but with selective disclosure can make this easier.

6

Thanks for your reply. Both documents are excellent as far as they go. I begin to understand mechanisms such as claims. The limitation of the first is that while excellent on describing a model for credentials it does not establish how the subject of a credential can control access to it by others. This was the big claim for Solid Project (SP). After all the subject may be paying for them and stores them in a/the WebID Pod.

Considering the concept of a form mentioned above, the hope for lazy people like me is that I bind my WebID to a form and add other information, and I control who can see what on the form according to a mix of privilege/role, explicit access by a named person (eg an advisor to me) and the world. HMRC could issue a tax return form to me, so some of their staff may have roles in its processing. My accountant has also got some access etc., but I might later revoke that access! I’d like the form application to fill in as much as possible automatically from my WebID whenever it is viewed.

The specs above involve lots of coding by every application, when if a RDF were encapsulated as an object life would be simpler for developers. All RDFs would have a render method. In some cases such as a WebID a mapping from the RDF to the form might be useful. I assume SOLID was referring to SOLID - Wikipedia.

The world is a very leaky place these days. Miners go taking advantage so that even claim of an age range can get exploited to work out your age to a higher degree of accuracy than allowed. The credentials document has too many issues that need to be addressed, but there is lots of good stuff.

Phil

7

SOLID is the acronym of SOcial LInked Data, with linked data really meaning the RDF ecosystem.

If you make a POD using Inrupt right now, the current setup is a display of your web ID at some id.inrupt.com uri, and allows some limited editing form factor.

I think I may be misunderstanding, but the WebID should generally be publicly discoverable for readability purposes. The extendedProfile documents are the extra documents that you may want to be associated with your profile. I’ll try to explain more thoroughly using tax documents as a case argument.

Your WebID could contain a link to the extendedProfile URI. If you have multiple different providers for services, you would grant them access to read (GET) the links for the contents of what is in your extendedProfile directory. Other users would not be able to do this by default.

These providers with access could use an application to navigate to your webID, read it (GET), parse out the extendedProfile URI (RDF/TTL parsing), then read (GET) the links for the list of resources stored in your extended profile directory (RDF parsing). The tax provider then finds the tax document resource and reads it, since you have allowed permissions to them to read the resource.

The links portions are in bold because there is a difference between reading the contents of a directory, which are unprotected, compared to reading a link to new content which can be protected by WAC/ACP.

Essentially, the flow is a very simple algorithm of attempt access, get, parse for a specific uri, attempt access, and the cycle repeats.

The issue with any flow like above is the read access is permanent unless revoked. There are some workarounds to this, such as having a statically registered client managing access updates based on a clock and/or signals (which I have played with a bit), or using the access grants specification.

Concerning the issue of privacy leakage, I’ve had thoughts about this myself regarding a minimal claims set. In the USA, drinking age is 21. When I go to a liquor store and they ask to see my ID, it shows my full birthdate. This is a valid but leakage prone way to request this information. If instead I had a verified card that was issued to people once they turned 21, and had my face on it and some stored proof on hardware, then I could simply give that to the clerk and they swipe it and it verifies.

Essentially, you would want your requester to honestly request the minimum amount of information necessary, but I am unsure of how to incentivize this behavior.

1 Like