Requirements.md

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?
• Login information on every App:
  • Green -> You are logged in\
  • Red -> You are not logged in
  • 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

• VC and token validation on the auditing frontend
  • 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

• The system needs to facilitate the exchange of the data (date of birth).
  • A date of birth must be available at some location in the dataspace
• The system needs to provide the store with the trust that the data is correct.
  • The stored DOB must be a verifiable credential
  • The stored credential must be verifiable on the store backend
• The system needs to provide the person with the trust that their data will only be used for age checking.
  • 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”.
  • The system needs to be able to store a generic policy
  • An interface needs to be available to store this policy
  • The policy must be modeled in an appropriate way
• 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
• The system allows the above interaction to take place without the person having to click on any dialogs.
  • 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.
  • A backend storage must be in place for the store
  • The store website must forward data storage and checks to the backend
• The system allows the person to check that their data was used correctly.
  • An auditing routine must be built in the store backend
  • An auditing routine must be built as a frontend interface
• The Government VC Service
  • Must be able to create a VC
  • 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
  • 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)
  • Create logging interface
  • Log Instantiated Policies
  • Log Access Grants
  • Log Operations
• Authorization system
  • include logging endpoint
  • include authorization endpoint
  • include policy management endpoint
• Mock Policy instantiation
  • Write out policy model that works for demo
  • ??? Discover existing policies to instantly grant some access
  • Link generic - instantiated - grant - operation
• Negotiation implementations
  • 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?