Capability URLs

[srosset81]

Capability URLs are another way to handle autorisations. Instead of writing somewhere that "Alice is allow to use Car X", we simply hand over a key to Alice, and this key is the "proof" she can use the car.

With Capability URLs, we could share links with people, giving them the right to edit a given ressource.

The authorisation could be shared through ActivityPub or any other mean of contact.

Implementation

Capabilities could be ressources, and use the same ontology as WebACL.

{
  "@id": "https://myserver.com/capabilities/k3kleict5ks3r4",
  "@type": "acl:Authorization",
  "acl:accessTo": "https://myserver.com/resource/x",
  "acl:mode": "Write"
}

Capability URLs may also indicate who is allowed to use the "key". We could use the acl:agentClass for that.

They can also have an expiration date.

These ressources should not be listed in the LDP container, nor queriable through SPARQL. Maybe they shouldn't be readable by anyone but Moleculer, but in this case, the frontend wouldn't be able to know if a capability URL is valid or not until the POST/PUT request is made (which is not ideal).

The URL of the capability (https://myserver.com/capabilities/k3kleict5ks3r4) could be passed in the headers when we want to edit a ressource. This would be passed in addition to the JWT token.

The validation could be handled by a Moleculer middleware, coming before the WebAclMiddleware.

In the frontend, we could add a dialog to generate capabilities URLs, like it is done in Google docs.

[srosset81]

@nikoPLP Qu'est-ce que tu penses de cette proposition ?

Je me tâte pour l'utiliser pour inviter des utilisateurs sur ActivityPods. Grosso modo, lorsqu'on est invité, on pourrait générer une resource de type "Capability" (une clé) qui donne le droit de temporairement voir le profil de notre "inviteur". Une fois qu'on a accepté l'invitation et qu'on est en contact avec la personne, la ressource est supprimée. On pourrait aussi imaginer qu'elle expire après un temps T.

J'ai l'impression que c'est simple à implémenter (dans notre architecture actuelle) et qu'au niveau ontologique on peut rester proche de l'ontologie WAC existante.

[srosset81]

Done