Merge pull request #45 from SolidLabResearch/project/pacsoi-poc1

Merge pacsoi branch into main

Author: joachimvh

.dockerignore

@@ -0,0 +1,24 @@
+**/.classpath
+**/.dockerignore
+**/.env
+**/.git
+**/.gitignore
+**/.project
+**/.settings
+**/.toolstarget
+**/.vs
+**/.vscode
+**/*.*proj.user
+**/*.dbmdl
+**/*.jfm
+**/charts
+**/docker-compose*
+**/compose*
+**/Dockerfile*
+**/node_modules
+**/npm-debug.log
+**/obj
+**/secrets.dev.yaml
+**/values.dev.yaml
+LICENSE
+README.md

.gitignore

@@ -67,3 +67,4 @@ tmp
 
 # Misc
 .DS_Store
+.vscode/

.syncpackrc

@@ -0,0 +1,10 @@
+{
+  "versionGroups": [
+    {
+      "label": "Use workspace protocol when developing local packages",
+      "dependencies": ["@solidlab/uma-css", "@solidlab/ucp", "@solidlab/uma"],
+      "dependencyTypes": ["prod", "dev"],
+      "pinVersion": "workspace:^"
+    }
+  ]
+}

Dockerfile

@@ -0,0 +1,28 @@
+FROM node:20.0.0
+ENV NODE_ENV=production
+WORKDIR /usr/src/app
+# COPY ["package.json", "package-lock.json*", "npm-shrinkwrap.json*", "./"]
+# RUN npm install -g yarn
+         
+COPY . .
+
+ENV YARN_VERSION 4.0.0
+RUN yarn policies set-version $YARN_VERSION
+
+RUN corepack enable yarn
+RUN yarn install
+# COPY . .
+
+RUN yarn build
+
+EXPOSE 3000
+EXPOSE 4000
+EXPOSE 4444
+EXPOSE 5123
+EXPOSE 8201
+EXPOSE 8202
+EXPOSE 8203
+
+RUN chown -R node /usr/src/app
+USER node
+CMD ["yarn", "start:demo"]

README.md

@@ -1,28 +1,26 @@
-
-# SolidLab's User Managed Access 
+# SolidLab's User Managed Access
 
 This repository contains SolidLab research artefacts on use of UMA in the Solid ecosystem.
 
 
 ## Packages
 
-- [`@solidlab/uma`](packages/uma): Experimental and opinionated implementation of [UMA Grants](https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html) and [UMA Federation](https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html). 
+- [`@solidlab/uma`](packages/uma): Experimental and opinionated implementation of [UMA Grants](https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html) and [UMA Federation](https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html).
 
-- [`@solidlab/uma-css`](packages/css): UMA modules for the [Community Solid Server](https://github.com/CommunitySolidServer/CommunitySolidServer/). 
+- [`@solidlab/uma-css`](packages/css): UMA modules for the [Community Solid Server](https://github.com/CommunitySolidServer/CommunitySolidServer/).
 
 - [`@solidlab/ucp`](packages/ucp): Usage Control Policy decision/enforcement component.
 
-
 ## Getting started
 
-In order to run this project you need to perform the following steps. 
+In order to run this project you need to perform the following steps.
 
 1. Ensure that you are using Node.js 20 or higher, e.g. by running `nvm use`. (see [.nvmrc](./.nvmrc))
-1. Enable Node.js Corepack with `corepack enable`.
-1. Run `yarn install` in the project root (this will automatically call `yarn build:all`).
-1. Run `yarn start:all`.
+2. Enable Node.js Corepack with `corepack enable`.
+3. Run `yarn install` in the project root (this will automatically call `yarn build`).
+4. Run `yarn start`.
 
-This will boot up a UMA server and compatible Community Solid Server instance. 
+This will boot up a UMA server and compatible Community Solid Server instance.
 
 You can then execute the following flows:
 
@@ -34,16 +32,22 @@ You can then execute the following flows:
 
 `yarn script:flow` runs all flows in sequence.
 
+As we are still in the progress of documenting everything,
+the above scripts are the best way to learn about how everything works.
 
 ## Demonstration
 
-A more extensive example of a real life use case has been implemented as described in [./demo/README.md](./demo/README.md).
-
+Instead of running `yarn start`, you can run `yarn start:demo` to start the server with an alternative configuration.
+With this configuration you can run the `script:demo`,
+which runs with experimental contracts.
 
 ## Implemented features
 
-The packages in this project currently only support a fixed UMA AS per CSS RS, and contain only the trivial [AllAuthorizer](packages/uma/src/models/AllAuthorizer.ts) that allows all access. More useful features are coming soon ...
-
+The packages in this project currently only support a fixed UMA AS per CSS RS.
+Authorization can be done with a simple, unverified, WebID embedded in the ticket
+using the [WebIdAuthorizer](packages/uma/src/policies/authorizers/WebIdAuthorizer.ts)
+or the [PolicyBasedAuthorizer](packages/uma/src/policies/authorizers/PolicyBasedAuthorizer.ts)
+which supports simple ODRL policies.
 
 ### Usage control policy enforcement
 
@@ -56,10 +60,10 @@ Used for creating a modular engine that calculates which access modes are grante
 For more information, you can check out its [own repository](https://github.com/woutslabbinck/ucp-enforcement) which has three engines that use [ODRL rules](https://www.w3.org/TR/odrl-model/).
 
 A test script is provided for a CRUD ODRL engine: `yarn script:ucp-enforcement`.
-In the [script](./scripts/test-ucp-enforcement.ts) a read Usage Control Rule (in ODRL) is present together with N3 interpretation rules. 
+In the [script](./scripts/test-ucp-enforcement.ts) a read Usage Control Rule (in ODRL) is present together with N3 interpretation rules.
 Then a read request is performed using the engine, which results in a list of grants. This list is then printed to the console.
 
 
 ## Next steps
 
-Have a look at the [milestones](https://github.com/SolidLabResearch/user-managed-access/milestones) we set for ourselves, and other [issues](https://github.com/SolidLabResearch/user-managed-access/issues) we would like to solve.
+More advanced ODRL evaluation can be found in the `feat/ODRL-evaluator` branch.

Requirements.md

@@ -0,0 +1,119 @@
+# TODOs for end-to-end requirements:
+
+## Final sprint
+
+- [ ] load generic and instantiated policies in auth frontend
+- [ ] update continuation screens in the shop frontend
+- [ ] MAKE THE VIDEO
+  - [ ] show credential, policies -> buy item -> show instantiation that has been added for the user -> show auditing trail
+- [ ] Write setup requirements
+- [ ] Create new SolidLabResearch repository that links to the e2e/setup branch
+
+### To Fix By Demo
+
+- [ ] Add Policy Screen update
+- [ ] Final fixes generic policy
+- [ ] Change trust display on auditing screen
+  - [ ] Change contract to "Instantiated Policy"
+  - [ ] Instantiated Policy -> Trusted instead of verified, age  keep verified
+- [ ] Auth app -> My pod app
+  - [ ] My Data
+  - [ ] My Policies
+  - [ ] Relevant linking?
+- [X] Login information on every App: 
+  - [X] Green -> You are logged in\
+  - [X] Red -> You are not logged in
+  - [X] Blue -> Auditer 3 is logged in
+- [ ] Store login buttons:
+  - [ ] Remove its'me option
+  - [ ] Continue as Ruben -> Share WebID link (with profile avatar) (This is not a Login!)
+
+
+
+
+
+### HAS TO HAPPEN
+- [X] VC and token validation on the auditing frontend
+  - [X] Represent this with green checkmarks in the frontend
+- [ ] Check policy models
+
+### If there is time
+- [ ] Check policy evaluation system
+  - [ ] Do time related policies work?
+  - [ ] Can we include wrong purposes that fail?
+  - [ ] Can we do a check on store registration
+- [ ] Store decision to give purchase access or not in the audit entry?
+
+### If there is a lot of time
+- [ ] Pod-based logging (not super necessary atm?)
+- [ ] Can we model accesses by 2 different people?
+
+## Assignment minimum requirements
+- [X] The system needs to facilitate the exchange of the data (date of birth).
+  - [X] A date of birth must be available at some location in the dataspace
+- [X] The system needs to provide the store with the trust that the data is correct.
+  - [X] The stored DOB must be a verifiable credential
+  - [X] The stored credential must be verifiable on the store backend
+- [X] The system needs to provide the person with the trust that their data will only be used for age checking.
+  - [X] The policy system must be able to handle a purpose
+- [ ] The system allows the person to specify in advance the generic policy that “all Belgian stores are allowed to read my date of birth”.
+  - [X] The system needs to be able to store a generic policy
+  - [X] An interface needs to be available to store this policy
+  - [ ] The policy must be modeled in an appropriate way
+- [X] The system automatically instantiates the above generic policy into the concrete case that “MyBelgianWineStore is allowed to use my date of birth from 2024-03-01 to 2024-03-15 for the purpose of age verification for purchases”
+  - [ ] MOCKED -> double check though
+- [X] The system allows the above interaction to take place without the person having to click on any dialogs.
+  - [X] The interaction is automatic after a WebID button is clicked to show what is happening.
+- [ ] The system allows the store to prove that they were allowed to perform the age verification.
+  - [X] A backend storage must be in place for the store
+  - [X] The store website must forward data storage and checks to the backend
+- [X] The system allows the person to check that their data was used correctly.
+  - [X] An auditing routine must be built in the store backend
+  - [X] An auditing routine must be built as a frontend interface
+- [ ] The Government VC Service
+  - [X] Must be able to create a VC 
+  - [X] VC must be transfered to demo pod storage -> Not required for Demo because of fixed keypair seed
+  - [ ] VCs can be validated on the backend of the store
+- [ ] The Auditing use-case
+  - [X] The store backend provides the option to retrieve all required data to audit
+  - [ ] This can be represented in an auditing browser app that shows colors when verified (token + VC)
+
+
+Small note with using the UMA server token signature as the contract signature.
+We can only trace this back to the UMA Server, and cannot reliably check the connection between the WebID and the UMA Server
+
+Another idea: preemptive auditing:
+- The store has to advertise who is auditing them
+- The contract has to be signed both ways
+- upon agreement, the data is sent to the store AND to the auditing service.
+- on auditing, the service can check if the store is withholding information
+  
+
+
+## Demonstrator requirements
+- [ ] Protocol message modelling
+  - [ ] claim request messages
+  - [ ] claim provision messages
+- [ ] Logging system (no hard requirement)
+  - [X] Create logging interface
+  - [ ] Log Instantiated Policies
+  - [ ] Log Access Grants
+  - [ ] Log Operations
+- [ ] Authorization system
+  - [ ] include logging endpoint
+  - [ ] include authorization endpoint 
+  - [ ] include policy management endpoint
+- [X] Mock Policy instantiation
+  - [ ] Write out policy model that works for demo
+  - [X] ??? Discover existing policies to instantly grant some access
+  - [ ] Link generic - instantiated - grant - operation
+- [x] Negotiation implementations
+  - [X] Return instantiated policy requirements from ticket resolving function to create a signed instantiated policy to return
+- [ ] Signatures
+  - [ ] Create a VC form an instantiated policy - I use the return JWT as a free signature
+  - [ ] Create verification endpoint for issued VCs 
+- [ ] Government mockup
+   - [ ] Create verification endpoint for issued VCs (can be mocked)
+- [ ] Client
+  - [ ] Make some mock-up of how storage could be handled in a way that allows for auditing
+  - [ ] Recurring requests make use of the same grant?

demo/README.md

@@ -0,0 +1 @@
+<this> <is> <smartwatch> <data>.