solid / solid

Solid - Re-decentralizing the web (project directory)

Solid

Re-decentralizing the Web

Solid is a proposed set of standards and tools for building decentralized Web applications based on Linked Data principles.

Read more on solidproject.org.

solid's Issues

What happens if I delete my webid card?

Should we allow users to delete their own WebID profile card? (They won't be able to log in or access the account, if that happens, so this would essentially be deleting their account).

Given that we intend to have a separate API for deleting accounts, how do we prevent users from deleting their profile? Do we intercept the request, and redirect them to the start of the Delete Account workflow? Do we just not allow it, via ACL?

(moved from solid/solid-spec#51)

Develop additional authentication mechanisms to run alongside WebID+TLS

Develop an alternative mechanism to the current in-browser-only certificate-based WebID authentication workflow.

Note: This is part of a two-pronged approach - 1) continue to improve the browser's certificate management UI and overall user experience (possibly get in touch with the browser vendors), and 2) (this issue here) develop a short-term alternative to WebID-TLS.

Friction points with current approach

• Firefox bug requiring browser restart when first signing up for a WebID
• User unfamiliarity with certificate management
• Lacking or limited support in several browsers (Internet Explorer, mobile browsers, etc)
• Lack of Log Out capability
• No good story for use on public/shared computers
• Limited or confusing UI for many use cases:
  • no good way of determining which app/browser tab is requesting a certificate (the UI only shows what datastore is being accessed)
  • difficulty in managing multiple identities, once a user has a handful of certificates
  • initial confusion when first using a Solid app, before a user has a WebID
• Current browser-centric focus makes it difficult for non-Javascript programming languages to interact with Solid

Possible Approaches (Proposals so far)

1. Username & Password authentication to a user's pod, and the pod would proxy requests (possibly using parts of the WebID Delegated Requests mechanism) to other pods
   • see "Extending the WebID Protocol with Access Delegation" paper
2. WebID RSA proposal
   • http://caniuse.com/#feat=cryptography
3. Use HTTP-Signature instead of WebID-RSA
   • IETF Draft 5 - Signing HTTP Messages
   • node-http-signature - Joyent's Node.js implementation of HTTP Signatures (see also their http_signing.md doc)
   • solid/spec/issue #5 for more HTTP Signature discussions
4. Sandro's Spot spec.
5. indieauth (see IndieAuthProtocol) / distributed-indieauth

Related / Helpful Reading

The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes - a remarkable paper evaluating 20 years' worth of authentication schemes, and rating them on various criteria (security, usability, ease of deployment, etc).

W3C Credential Management Level 1 recommendations

Wikipedia entries: https://en.wikipedia.org/wiki/Single_sign-on and https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations

JSON Web Tokens

W3C FIDO 2.0 Platform Specifications (see W3C Welcomes the FIDO 2.0 Member Submission post)

• FIDO 2.0: Web API for accessing FIDO 2.0 credentials
• FIDO 2.0: Key Attestation Format
• FIDO 2.0: Signature format

W3C Good Practices for Capability URLs

indiecert/auth and Introducing IndieCert blog post

• https://indiewebcamp.com/authorization-endpoint

WebDHT

YouID

The term "Container" is now overloaded and underspecified

Some related problems:

Solid "containers" add many features to ldp:BasicContainers, most obviously having the URLs related to containment. We've talked about proposing ldp:HierarchicalContainer as a flag for this. There's also globbing, SPARQL, and probably several other features added. Within the protocol we need names for these features, or collections of these features, so we can detect them.

In NoSQL databases like Mongo, I think these things are usually called Collections, not Containers.

The term "container" has recently become strongly attached to OS-level virtualization (LXC, vagrant, docker, sandstorm). I've heard people confused by solid containers because they think we're talking about these.

Suggestion: in the documentation and toolkits, call them Folders. Maybe in the HTTP headers, too, when we get there.

Multiple ways to state the same ACL

As I read the specs,

[ :agent <alice>; :accessTo <foo>; :mode :Read, :Write ]

means exactly the same thing as:

[ :agent <alice>; :accessTo <foo>; :mode :Read ]
[ :agent <alice>; :accessTo <foo>; :mode :Write ]

Having two ways to say the same thing complicates every system that has to read or edit these things, and quite possibly will be a source of errors that results in unauthorized access being granted.

Suggestion: only allow one mode arc per Authorization (ie restrict the data shape)

See also #32 which is about this kind of thing with :agent and :accessTo. This is a separate issue because I expect this one to be much more controversial.

revised proposal: server must normalize ACL graphs. See below, esp #34 (comment)

Delegating authentication to the pod to allow pod-to-pod communication

At some point, it will be required that a pod sends messages or read/write a resource from/to another pod (ex: notifications or messaging in a chat app). How a secure connection could be opened between the two pods without identifying each other via sharing their certificates? In other words, how the pod can speak on the user's behalf?

Name "defaultForNew" doesn't agree with semantics

People tell me defaultForNew actually means "default for when the ACL file is missing or maybe empty or maybe doesn't have any triples in it or maybe doesn't have the right kind of triples in it".

It should either be implemented as "default for new" -- meaning when a resource is created in a container, this is the ACL it's given -- or the name should be changed (and the exact conditions for when it applies should be specified).

I don't currently have an opinion which is better.

If the semantics stay as I believe they are implemented, then I suggest the name change to "background" (or something like that), but I don't know how to say when it applies. Every idea I can think of for that is a hack.

pod supports pluggable code modules.

This may be debatable. Is pod only for storage or could it support plugging some logic to run and do specific jobs. Ex: notification could be a clear example for a code module, cleansing module ... etc). Think of it as Triggers or Stored Procedures in relational DBMS.

The challenge is to define the sandbox that governs the access permissions and utilization of the system resources.

Creating new certificate issues

• I create a certificate with gold
• I create the same certificate with ldnode

Now I have two certificates

• I create the same certificate with gold again (nothing changes)
• I create the same certificate with ldnode again (nothing changes)

Hence the certificate is not updated.

We should look at this

Develop recommended Inbox semantics

The Inbox container is being created by default on account creation.
Need to discuss (and add to the spec) the exact behavior and semantics of the Inbox container.

Questions/considerations:

• How does a user grant fine-grained permissions to the Inbox (or is it all-or-nothing)?
• How does an app scan through the inbox efficiently for just the notifications they care about?
• Most importantly, does data expire from the Inbox? What are the cleanup/expiration semantics?
• Are the provisions to archive the data instead of expire it, somehow?

Add WebDAV COPY verb support

Add limited support for the WebDAV COPY method. (There is currently no easy way to transfer files from the client side from one URL to another.)

Enables:

• #12 - Enable users to migrate/copy their accounts to another server
• An easy way for client-side Solid apps to get data into a user's dataspace. (I ran into this limitation when implementing a 'Save to Pod' bookmarklet).

ACL Interaction:

Copying from a non-LDP public Web resource to a container:
A COPY operation requires that the authenticated user has Write access to the destination container.

Copying FROM an LDP container to an LDP container:
A COPY operation requires that the authenticated user has Read access on the source container, and Write access on the destination container.

Interfacing with actual WebDAV servers:
Out of scope for the moment. We just need this as a convenience method to move to and from Solid servers.

To Do:

• implement COPY verb on the server side, on ldnode
• add a helper method to solid.js

Data security on your pod

What happens if someone gains access to your pod, perhaps by cracking the OS, being the hosting provider, having legal authority, etc...?

Relevant work in this space includes:

• http://enigma.media.mit.edu/enigma_full.pdf

ACL Groups infinite loops

(Originally opened by @nicola)
Consider this scenario:

• Server A
  • Groups/WorkingGroup.ttl
  • Groups/WorkingGroup.ttl.acl (it says only B/Groups/Admins.ttl can read!)
• Server B
  • Groups/Admins.ttl
  • Groups/Admins.ttl (it says only A/Groups/WorkingGroup.ttl can read!)
  • Work/File.ttl
  • Work/File.ttl.acl (it says only A/Groups/WorkingGroup.ttl can read! )

Now, when one tries to access any file where WorkingGroup or Admins can read (e.g. B/Work/File.ttl.acl), each server will ask the other to read the group, which will need to ask the other to read the Group to read the permission to read the Group, but then the server will ask back to read the other Group to read the other group permissions and so on, in an infinite loop.

Currently affects gold, I have commented out groups in ldnode

(Moved from solid/solid-spec#71)

API for deleting accounts

Implement an API for deleting accounts/WebIDs.

• (as mentioned by @csarven). 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..."
• If the user is exporting their data prior to permanently deleting their account (as opposed to just moving somewhere else), should the server support the HTTP 410 Gone status code?
• Implementers should strongly consider supporting some 2-factor confirmation mechanism prior to deleting the account. (See the original deletion confirmation discussion)
• get consensus on the account deletion API (including suggested 2-factor confirmation mechanisms)
• implement on ldnode - see nodeSolidServer/node-solid-server#177
• write docs/examples
• add a 'Delete Account' button to the profile-editor app (which will start the deletion confirmation process)

(Moved from solid/solid-spec#67)

do we need acl:Control?

I implemented WebAccessControl in rww-play but could not find a use for acl:Control. I had trouble at the time also quite understanding how it would work. If I remember correctly its aim was to specifying access control restrictions on the acl file itself.

I was able to do without by specifying the following generic acls wac:includeed from other acls. Though one could do it on a case by case basis too.

[] acl:accessToClass [ acl:regex "https://jack.example/.*[.]acl" ];
   acl:mode acl:Read;
   acl:agentClass foaf:Agent .
[] acl:accessToClass [ acl:regex "https://jack.example/.*" ];
   acl:mode acl:Write, acl:Read;
   acl:agent <card#me> .

Presumably the acl file should specify itself as its own acl file in the http Linkheader (I don't think I have implemented that there.) Off the top of my head this should do:

Link: <>; rel="acl"

Send out welcome emails to newly created accounts (recommendation for servers)

If the user specifies the optional email address (used for account recovery, etc) on a signup app (such as solid-signup), send them a Welcome to <provider name>! / "welcome to Solid" sort of email.

Include:

1. Their WebID (that they can use for logins, etc)
2. Links to documentation / resources
3. Link to their Profile (via a profile editor)
4. The Account Recovery link

Considerations:

• This should definitely be a plugin-type mechanism (at very least, a config option for the solid server)
• Sending emails is operationally difficult (since they're prone to end up in spam filters, etc). Consider offering something like Sendgrid as an option for server operators.
• Some server operators might want to make the recovery emails required at signup, and have an "email verified" flag on the account.

Implementations:

• LDNode: nodeSolidServer/node-solid-server#195

Tutorials link at bit.ly down

Does solid use acl:accessToClass?

One can imagine how acl:accessToClass would be useful, but I haven't heard of anyone using it. So do we mandate it be implemented in solid servers or leave it out?

suggestion: leave it out for now, at least

Move 'WebID Delegated Requests' spec section to proposals

Since the WebID Delegated Requests section is experimental / not yet implemented, and requires further discussion, let's move it to solid/solid/proposals.

Document/provide recommended workflow for Decentralized Aggregation

Given that Solid is aimed at building social media applications, we need to have a clear set of recommended solutions for content aggregation.
(See for example the original How are inboxes handled? issue, or the Read Social Stream User Story it references).

We need to document at least the following approaches available to Solid developers:

1. Client-to-client aggregation, with a designated "Host" user that stores the content. (Mention where the primary data is stored, versus notifications that the data was posted, versus an Activity Log record of user-generated events).
2. Client-to-client aggregation, symmetrically replicated to all participating clients.
3. Client-server aggregation (what most web developers are currently used to). Document how the Solid API can be used by non-Javascript languages. May require either an Alternative mechanism to WebID-TLS, or just better documentation of command-line (using curl, for example) wrangling of crypto certificates.

Implement server-side /logout functionality

(Moved from solid/solid-spec#74).
WebID-OIDC:

• node-solid-server: issue #388 - Implement logout

WebID-TLS: - Not currently possible, won't implement.

During the current WebID-TLS workflow, there's no way for a client to request to Log Out (stop authenticating as a particular WebID user / certificate).

Implement a privileged "admin" user on Solid servers

Implement a privileged admin/root user on Solid servers.

1. The admin user id (in the form of a WebID) will be passed (as a command-line argument or config option) to the server on startup.
2. This privileged admin user will have the ability to edit all other users' ACLs, and is to be used in the classic unix root user sense, for administration, account management and reporting.

This user can also be given access to an administrative-type app (Warp at first, but dedicated apps later on) which would give them an idea of system usage (how many users are on this particular server, what their disk usage is, etc, etc).

(action item from the Fri Jan 8th 2016 dev meeting)
(Moved from solid/solid-spec#66)

To do:

• Implement on LDNode. (done - nodeSolidServer/node-solid-server#205)
• Document on LDNode readme
• Document on solid spec in the server recommendations section

Security between apps

This might split off into a dozen issues, but let's start with one.

In solid today, every application has the same access to your pod. It can read all your data, delete all your data, and write new data wherever it wants in your storage. It can use your contact information to put customized messages in the inbox of each person you knows with an inbox. It can send a copy of all your data to a secret server, with or without telling you. It can blackmail you or ask for ransom.

It's like desktop software, for better or worse.

To expose yourself to this, you have to visit a website with malicious code (and sometimes do a webid login). This might happen because you have been tricked into visiting the site (check out this new solid app!), or it might be a site you trust which has become infected.

In this sense, solid is no worse than many browser security bugs that have allowed malicious websites to take over the machines of people who visit. Still, I don't think any vendors purposely choose to give their browsers such vulnerabilities, and if they did, I don't think the customers would be at all happy about it. So we should probably figure out how to tighten this up before users do anything important with solid.

I've heard several ideas about how to solve this problem, but it's not clear to me how to put them together in a way that works.

1. A "trustworthy app" certification program (also called "beneficent apps")
2. Each app-provider or app-version needs to obtain your permission before interacting with your pod or someone else's pod in particular ways, like reading your contacts, or your financial data, or writing to a friend's inbox. Origin fields in permissions are a way to implement this.
3. Apps run in some kind of sandbox/jail so they need to ask permission before making HTTP requests to random servers (things not your pod).
4. Apps are run from your own pod, so you have a copy of the code, in case forensics are needed, and to ensure permissions are given to only a particular version

Listing containment triples and ACL

Listing containment triples should not show the RDF type of a resource if this resource has an ACL that doesnt give access to the current Agent

Firefox bug - WebID/certs don't work after signup unless restart

We've encountered this bug several times during the Hackathon, and I just saw a user encounter it again.

Basically, after first going through signup (on Databox.me) and getting their first WebID and certificate, logging in to any of our apps doesn't work on Firefox.
Users have to restart their browser first, and then they can log in and use certificates as usual.

So, we need to:

• Track down the cause, and either fix it on our end or somehow open an issue with Firefox
• Tell users to restart their browsers after signup (see solid-contrib/solid-signup#9)

Do we need APIs for account management?

(Moved from solid/solid-spec#69, originally opened by @nicola)

In this issue I bring back this conversation we had in October.
Quick note: this aims at future Solid specs, also it is more of a discussion than a proposal.

We use special APIs for account management, do we really need them?

Non-LDP API (current)

• Creating an account: POST https://databox.me/,system/newAccount
• Deleting an account: POST https://databox.me/,system/deleteAccount (I assume)

LDP API (possible)

• Creating an account: POST https://nicola.databox.me/
• Deleting an account: DELETE https://nicola.databox.me/

Note: Certificate generation with Keygen should be added - somehow
Note: this example assume that each new account will be in a subdomain (although Suborigins will eventually make subfolder webids possible)

However, I do see the value of non-ldp APIs (they basically solve the issues explained in the two "notes", and they are not really intrusive as of right now, see the 2-factor deletion discussed in solid/solid-spec#67), however keeping with consistency would be great!

Open for feedback!

(conversation started several times with @deiu that already super simplified the process, and with @dmitrizagidulin recently)

Describe and Support Friends&Family Servers

People should be able to give out accounts to relatively-trusted people on the same domain.

It's the same domain so they don't need a wildcard SSL. Folks have to be somewhat trusted because if they install html+js files on their pod, they can see each other's cookies.

The motivation here is to provide a viral vector where the early adopters in each community can help spread the technology to their associates.

Move 'WebID+RSA' spec section to /proposals

Since the WebID+RSA section is still in the experimental/proposal stage, let's move it to solid/solid/proposals.

Use Case: storing WebCrypto generated public key for an app

I have a simple foaf-browser application that can produce a public key using Http-Signature ((but this issue would be the same were I to use webid-rsa)). I can't really test it without saving that key. So I need a space for the application to save that key which can then identify the application when used by that browser.

API to allow cloning of git repos directly into dirs

(Originally opened by @deiu)

This could be useful for cloning web apps directly into the user's data space.

(Moved from linkeddata/gold#30)

Document proposal-based Solid project workflow

• Create /proposals folder in this repo.
• Move existing discussion/proposal .md docs from solid-spec and into individual PRs to solid/solid.
• Add documentation of the process into the READMEs of solid/solid and solid/spec

wac:origin

wac:origin is defined on the WebAccessControl wiki page and is pretty useful, as it can allow an application to protect a space only for applications coming from that origin, even if all the applications authenticate using WebID-TLS. This solves issue 44: Every App has root problem.

As I understand it is already implemented, so that's why I am opening an issue here.
Who has implemented it?

Issues:

• wac:origin is defined in the WebAccessControl wiki page but is not in the wac ontology
• The wac:origin example needs to be changed from

[] acl:accessToClass [ acl:regex "https://bblfish.solid.example/.*" ];  
   acl:mode acl:Write; 
   acl:agentClass [ acl:origin <https://apps.rww.io/> ] .

to

[] acl:accessToClass [ acl:regex "https://bblfish.solid.example/.*" ];  
   acl:mode acl:Write; 
   acl:agent [ acl:origin <https://apps.rww.io/> ] .

because otherwise one cannot create classes of origins which one should trust. Ie. one wants to
be able to create one or more trusted app groups:

<#trustedApps> a foaf:Group;
     foaf:member [ acl:origin <https://medical-status.apps.rww.io/> ],
                 [ acl:origin <https://blood-sugar-history.apps.hi-project.org> ] .

which could then be used in ACLs like this:

[] acl:accessToClass [ acl:regex "https://bblfish.solid.example/medical/.*" ];  
   acl:mode acl:Write; 
   acl:agentClass <#trustedApps> .

I would like to change my webID address

It would be nice if I can click on the webID and customize it. Perhaps, a click on the webID will direct me to a new page to edit it or open up a pop up window.

Document Query use cases

There are many places where it seems to make sense to have the server support some form of query. This could be done by adding a QUERY verb or even potentially allow GET to accept a body with a query. (see thread Proposed HTTP SEARCH method by the LDP group in April 2015 to the HTTP mailing list.

This is quite a lot of work to implement, so it should only be done when it is clear what the value of doing it is.

There usually are ways of doing things without such a query feature, but doing it that way may actually make things much more complex. We'll only know if we document the cases where a decision was made to do things one way, that could have been achieved more easily with a query.

I opened up a wiki page to document such use cases: Query Use Cases

regexes in ACLs

rww-play implements regexes for WebAccessControl as lightly documented on the WebAccessControl wiki page. This allows one to set access controls for a whole number of resources in a space.

An example given in issue 51: Do we need wac:Control is

[] acl:accessToClass [ acl:regex "https://jack.example/.*[.]acl" ];
   acl:mode acl:Read;
   acl:agentClass foaf:Agent .
[] acl:accessToClass [ acl:regex "https://jack.example/.*" ];
   acl:mode acl:Write, acl:Read;
   acl:agent <card#me> .

the implementation is quite simple in WACAuthZ mostly because it relies on Java Regular Expressions. JS Regular expressions work differently, and may also be different to Powder regex.

This is quite powerful, as shown in the example above. But perhaps there is no need for something quite that powerful and a simpler regex language would do, that may not have the complexity of regular expressions which can be turing complete (verify).

Issue: the above example does require a client to know that the ACL for a resource has a particular extension. How would it find that out?

Disable random slug generation for containers

During a POST request (with a Slug header set), the server may decide to create a random string that gets appended to the Slug value, if a resource with the same name already exists. While this feature is really useful for creating random resources (i.e. files) inside a container, it seems to be very annoying when applied to creation of containers.

I personally feel that most applications and users care a lot about the names of containers, and less so for resource names (which can sometimes be random).

My proposal is to drop this behavior when it involves container creation, and respond with a 409 - Conflict if a container with the same name already exists.

Get rid of foaf dependency in ACLs

Right now the universal ACL is defined in the spec in terms of foaf:Agent. This makes a critical security system (acls) dependent on an ontology maintained without an open governance process or organizational backing.

Suggestions: use rdfs:Resource instead of foaf:Agent.

develop a PATCH protocol using dataset normalisation

DataSet normalisation is important for signing graphs. One proposal is RDF Dataset Normalization developed by Digital Bazaar @msporny and @dlongley .
This allows one to sign graphs containing bnodes, by detailing a proceedure to name bnodes in a graph in a deterministic way.

This can be used to create a very simple and efficient PATCH protocol to allow PATCHing graphs with bnodes that would function like this:

1. the client normalises the graph
2. this can be used to create a very simple PATCH for graphs containing bnodes
   such as PATCH ADD { :normalisedbnode_1 foaf:knows :normalisedbnode_2 . }
3. connect to the resource send the PATCH
4. the server normalises the graph, applies the patch to the normalised graph, and can then translate those changes if needed to the original graph.

done.

This can be used to resolve the main bnode issue.

This does not mean of course that one should only use bnodes.

Note: it may be that the graph normalisation needed for this is a subset of the graph normalisation needed for signing graphs.

Document/discuss running Solid servers in multi-user vs single-user modes

Solid implementations (gold, ldnode) currently assume a multi-user data service provider use case (such as Databox.me). Some Solid server should also support single-user mode -- see nodeSolidServer/node-solid-server#201 for specs/discussion.

Serve Solid favicon.ico if they don't exist

To avoid serving 404

definition of space:AppIndex

By application

A list (public or private) of

  <#me>  space:AppIndex  <byType>.

And then in there things like

 <#r5>  a solid:AppRegistration;
  solid:forApp  ghld:app-shedule
  solid:instanceIndex </polls/list.ttl>.

and then in /polls/list.ttl things like

<#i345> a solid:Instance;
  solid:forApp  ghld:app-shedule;
  dc:created 2012-12-09;
  solid:instance </polls/list3/congig#this>;

https://github.com/solid/solid-spec/blob/master/data-discovery.md

Questions:

• should appIndex be a small "a"
• is byType a .ttl file or container or could be eiether
• do we have a workflow to add terms to : http://www.w3.org/ns/pim/space

Standardize on the term "app" instead "skin" for viewers/editors/renderers

(Moved from solid/solid-spec#65.)

This first started as a discussion on PR 174, where I asked about the --skin command line parameter that's passed to ldnode to specify the default app it's going to use to render a resource.

"Skin" is an overloaded term, that most developers and web users understand to mean in the UI sense, a "theme". What is currently referred to as a "skin" by Solid devs, is the bit of app code (a viewer/renderer/editor etc) that is presenting the resource that's being browsed. So, for example, Warp is a "skin", since it determines how a particular resource (the file or directory being browsed) is displayed.

(@csarven suggested the term "default app", in that initial discussion.)

In the Fri Jan 8th team dev meeting, we discussed this issue again. There seems to be a general consensus that we should rename the term.

The question is - to what.

The candidates mentioned so far are:

1. "default app"
2. "fallback app"
3. "suggested app" or "preferred app"
4. "viewer" or "editor"
5. "opener"
6. "component" (in the Ember.js / Angular sense, which means "a view with some controller code/logic to go with it)
7. "renderer"

What would be your preferred term?

(Discussion-to-date summary: @deiu and @nicola is ok with standardizing on "app" terminology).

GSoC 2016

Solid somehow should participate in GSoC 2016.

Mentoring organization application deadline: 19 February 19:00 UTC
Timeline: https://developers.google.com/open-source/gsoc/timeline

Anybody willing to help with organizing this?

Replace Workspaces concept, standardize default account Containers

When a user creates a new account on a Solid compliant server, what sort of containers will be created for them by default? The current recommended procedure is described in the Personal Data Workspaces section of the Solid spec README.

After a series of dev meeting and in-person discussions with @deiu, @timbl and the rest of the team, a consensus has emerged to refactor these recommendations as follows:

A. Terminology

Change the "Workspace" terminology to just "default Containers". (The problem with the term "workspace" was that every single person involved in the discussion thought that it means something different.) So, these are simply a list of Solid containers that can be optionally created by a Solid server on account creation.

B. Names and ACLs of default containers

Recommend that Solid servers create the following list of containers, on account creation:

1. /profile/ (can be displayed as Profile in the UI) - The container which will house the WebID profile documents and its various components/linked docs. Default ACL: read-public.
2. / - the root/default container for the account. (Self-explanatory, currently done). Default ACL: private (owner only).
3. /settings/ (can be displayed as Settings in the UI) - The container which will house User preferences and settings, and optionally app preferences and configs. Default ACL: private (owner only).
4. /inbox/ (can be displayed as Inbox in the UI) - A container to serve as a default primary channel for notifications. Note that this is complementary (and not necessarily replacing) app-specific notification inboxes such as the one used by Dokeli. Default ACL: append-only by public, read by owner.

C. Discoverability

Given the Solid platform's emphasis on discoverability and the focus on "follow your nose", ensure that all of the default containers above are linked to (using appropriate vocab terms) from the WebID profile. To put it in other words - apps and developers should not rely on the hardcoded names of the containers, but only use them through the links in the WebID profile document.

Specifically:

/profile/ (Profile)

Implied (discoverable) from the WebID. As in, a user pastes in a WebID URL (so, currently, something like https://accountname.databox.me/profile/card#me, which de-references to a profile document containing, among other things:

<>
    a <http://xmlns.com/foaf/0.1/PersonalProfileDocument> ;
    <http://xmlns.com/foaf/0.1/maker> <#me> ;
    <http://xmlns.com/foaf/0.1/primaryTopic> <#me> .

/ (root)

Discoverable from profile via pim : space#storage property. (Currently done)

<#me>
    <http://www.w3.org/ns/pim/space#storage> <../> ;

/settings/ (Settings)

Discoverable from profile via pim : space#preferencesFile property. Currently specified as ../Preferences, proposed:

<#me>
    <http://www.w3.org/ns/pim/space#preferencesFile> <../settings/preferences.ttl> ;

/inbox/ (Inbox)

Discoverable from profile via solid/terms#inbox property. Currently specified as ../Inbox, proposed:

<#me>
    <http://www.w3.org/ns/solid/terms#inbox> <../inbox/> ;

To Do:

• edit the Solid spec to match this list
• make a PR to LDNode to set up these default containers on account creation (and make sure that they are linked to from the profile document). Issue: ldnode/190
• enhance Solid.js (or even just node-webid) to provide easy one-function calls to parse the links to these containers from a given WebID/profile combination. (solid.js/#31)
• get consensus on and clarify the read and write semantics for the /inbox/ container.

Delegation, Group ACLs, and confused deputy

As far as I can tell (untested and I'm not too familiar with the protocol), there's a confused deputy issue with how delegation and groups are handled that allows users without read access to the group definition to determine if a user is in a group.

Given:

Alice = Server A's owner
Bob = Server B's owner
Malory = An attacker who owns a file on servers A and B.
Club = A group managed by Bob

Malory defines a group Attackers with her as the sole member and overwrites her file on server B with this new group definition and changes the ACL to give the Club group read access. Malory then changes the ACL of her file on server A to only allow reads by the Attackers group. Malory then attempts to fetch the file from server A verifying that Alice is a member of the Club group.

The problem is that server A has the power to act as Alice but shouldn't be doing so in this case.

Implement a Statistics app for tracking e.g number of users on Solid server

(Originally opened by @timbl)

It would be good to have (by default) a public page/app on Solid servers which gives some anonymous stats like the number of users, mean and median number of triples/user, so we can see how things grow.

And link it maybe to and from a master list of Solid server installations (until there a million)

(Moved here from linkeddata/gold#38)

Document/Improve Account Recovery Workflow

1. Document the account recovery (and new certificate generation) API endpoints for Gold and LDNode (See also linkeddata/gold#68, for example).
2. On the 'enter your WebID' recovery screen, prompt the user for what their WebID looks like (e.g. https://accountname.databox.me/profile/card#me)
3. On the 'enter your WebID' recovery screen, display an error message when the WebID is not valid (does not point to a valid profile document).
4. Display an error message when there is no recovery email on file.
5. Improve the 'issue a new certificate' landing page (that the user goes to when clicking the link in the email).

I suspect this is currently a "hardcoded" app on each Solid server. Perhaps we should consider this to be a separate recovery app with its own Github repo.

ACLs shapes underspecified

Neither the ACL specs at https://www.w3.org/wiki/WebAccessControl nor at http://www.w3.org/ns/auth/acl.n3 tells us what this means:

[ a acl:Authorization,
  acl:agent <alice>, <bob>;
  acl:mode acl:Read;
  acl:accessTo <foo> ]

Does that mean alice and bob both have read access to foo? Or is it malformed?

Similarly, we could have multiple values for acl:accessTo.

If we allow it, it will probably cause problems for acl editors, possibly with dangerous results.

Suggested solution: don't allow it.

That is, say that ACLs must have a datashape where num(agent)+num(agentClass) == 1 and num(accessTo)+num(accessToClass) == 1.

In ShEx I think that looks like:

<Authorization> {
   (:accessTo | :accessToClass),
   (:agent | :agentClass), ...

Any violation of this shape should (1) generate an error (eg on patch/put) and (2) not grant access if it somehow got there anyway (eg by being already in the filesystem)

Implement a Welcome app (redirect to it after signup)

To improve the user signup experience, implement a Welcome / intro app which the user gets redirected to after completing signup.

The app should have the following initial functionality:

1. Display what the user's newly-created WebID is
2. Link to Profile Editor app (and preferably to a list of other apps to try)

See also:

• solid-signup/5 - Redirect user to their new account once signup is done
• gold/69 - After the cert has been issued, what then?

Implement (or Document) workflow for adding a new certificate to existing WebID Profile

1. Implement (or document, if already exists) the ability for a user to add an additional certificate to an existing WebID Profile. (Such as, if a user wants to enable another browser to access their existing account).
2. Add a link to 'Add Certificate' to https://github.com/linkeddata/profile-editor/

(See also #15, possibly)

all resources MUST have at least one "acl" Link relation

ACL resources are resources like any other and are themselves access controlled. Making the access control relations explicit via a Link header is very helpful if only to allow clients to be able to help read and edit these resources consistently.

The simplest (and current behavior of SoLiD) is to put the access control rule for the acl in the acl file itself. But how should a client know that this information will be used by the server as an acl rule? After all a user can place acl triples in the body of a normal non acl resource and this won't be acted upon by the server. A client furthermore may have no idea that it is looking at an acl file itself as it may have reached that file by following some non-acl-link from another document (potentially on another server). The usual answer is to put information controlled by the server in the HTTP header.

So the current behavior of SoLiD can be encoded using the Link header Link: <>; rel="acl" . As an example the following acl states that the resource </document.acl> can be read and written to by agent <card#me>:

GET /document.acl
...

200 Ok
Link: <>; rel="acl"
Content-Type: text/turtle
...

[] acl:accessTo <>;
   acl:mode acl:Write, acl:Read;
   acl:agent <card#me> .

What about the case when information about who can edit the acl file needs to be protected whilst the acl file itself needs to be public, or simply more widely readable? Two options present themselves:

1. the acl could point to yet another resource, with different access control rules with a header such as Link: <document.acl.acl>; rel="acl". Clearly there are pragmatic limits to how far such an acl of acl system should go, and so this MUST end with a resource that points to itself as its own acl.
2. The acl resource could be its own acl, but place the acl rules about who can edit it, in an acl:includeed resource that is itself protected.

Another use case may be the need to have a special admin user that can edit all resources on a site,
as required by issue 7: Implement a privileged "admin" user on Solid servers
This can be made explicit by a server pointing every acl point to itself, and to the admin acl .

Link: <>; rel="acl"
Link: <https://rww.io/admin.acl>; rel="acl"

This would allow the admin to use some administrative SoLiD based Application that would always give the admin rights whatever the self referring acl said, and without being editable by that user as would be the case in point 2 above.

It is most likely that most SoLiD system written initially will need only self referring acls. But keeping the door open for more complicated cases, and programming clients to work correctly with those, will allow these systems to work in more complex situations such as buisnesses, high security environments, etc...

As a side effect this patterns may also simplify the ontology by making the acl:Control type redundant. see issue 51: do we need acl:Control?.