Protocol for Usage Control Policies in Solid with defaults

[woutslabbinck]

Pitch

In the publishing world, resources become open source (i.e. fully public for everyone to see) after a couple of months. The resource owner and publisher of that resource, however, may on request still give manual access to people. E.g. a peer who wants to use the resource for research or a peer who paid for early access so access is granted under that condition.

A solution that allows for default Usage Control Policies (UCPs) while also endorsing manual interventions for specific resources would make such a use case possible.

Desired Solution

A protocol that defines how default UCPs can be applied for a set of resources (e.g. a container or Solid pod) that interoperates with people adding UCPs to specific resources in that set accompanied by a Proof of Concept that implements this protocol.

Acceptance criteria

• A protocol/specification about Usage Control Policies in Solid with defaults

• An implementation of that protocol such that at least the following flow is showcased:

  • A researcher A uploads publications (solid resources) to a personal Solid Pod A

  • Researcher A has an LDN Inbox

  • Researcher A publishes policies for access to new publications (E.g. a container that consists of the set of solid resources that are publications) on Solid Pod A

    • E.g. every resource in the publications container is open access 2 months after upload. However, per resource offers can be accepted to get access before the date which requires acceptance or rejection from researcher A

  • Solid Pod A has a discovery mechanism to find the LDN inbox for a publication

  • e.g. HTTP headers or a triple linking to the LDN inbox

  • Researcher B requires access to a publication on Solid Pod A and sends an LDN+AS2 Offer to the LDN Inbox corresponding to that resource.

  • type: Offer + some new type that defines a request for access Offer

  • actor: The WebId of Researcher B

  • object: The publication IRI (or a more elaborate payload that explains the reasons for access)

  • Researcher A evaluates the Offer in the LDN inbox:

  • Accept Offer:

    • The Solid Agent is made aware that the policy of researcher B is now active on the publication resource
    • A notification (LDN+AS2 'Accept') is sent to Researcher B (via its LDN inbox)
    • The Solid Agent grants (temporary, depending on policy) access to the publication resource to Researcher B

  • Reject Offer: A notification (LDN+AS2 'Reject') is sent to Researcher B (via its LDN inbox)

  • After a period of X (e.g. 2 months), the Solid Agent makes the publication resource publicly available

Pointers

• UCP demo
• Event Notification

Scenarios

• Challenge 78 (An extension that abstracts away the complexities of permissioning for resource sharing between users and apps)

[pheyvaer]

Challenges are meant for technical challenges and their corresponding solutions. Finding a protocol is not a technical challenge in that sense, as in it's not a implementation. A (draft) protocol can be input for this challenge, but it cannot be the output of this challenge.