Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protocol for Usage Control Policies in Solid with defaults #117

Open
woutslabbinck opened this issue Jul 3, 2023 · 1 comment
Open

Protocol for Usage Control Policies in Solid with defaults #117

woutslabbinck opened this issue Jul 3, 2023 · 1 comment
Assignees
Labels
challenge technical problem applied to a use case proposal: changes needed 👷

Comments

@woutslabbinck
Copy link
Contributor

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

Scenarios

  • Challenge 78 (An extension that abstracts away the complexities of permissioning for resource sharing between users and apps)
@woutslabbinck woutslabbinck added challenge technical problem applied to a use case proposal: pending ❓ labels Jul 3, 2023
@pheyvaer
Copy link
Contributor

pheyvaer commented Jul 4, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
challenge technical problem applied to a use case proposal: changes needed 👷
Projects
None yet
Development

No branches or pull requests

2 participants