# DICE demo

## Current state

We have a showcase that demonstrates how to authenticate to a virtual machine (VM) using SSH protocol, DKMS, ACDC and OCA.

#### How it currently works
- An owner of a TDA "app" (available for Android), the Issuer, issues the ACDC credential with embedded OCA Bundle.
- Another owner of a TDA "app", the receiver, gets the ACDC from the issue by scanning a QR code. QR code furthermore contains the OOBI of the Witness of the issue.
- Having the ACDC, the receiver uses it to get access to a VM. Under the hood the process looks like the following:
- the receiver runs `ssh vm_address` in the terminal
- terminal shows QR code
- the receiver scans above QR and magic happens

The component that does the authentication can be extended to authorization and for example also authorize to WEB-like services. On one angle lets add more supported protocols to the authorization component. This way one credential may be used to access more services, much like any token-based mechanism would work.

## Cross-governance showcase utilizing ChatGPT

There is another angle, however, that remains unsolved in most cases: how to proceed in cross-governance scenarios, where a party Z from framework A desires to perform an operation in a service from framework B. Since party has credential from A, how to enable access to a service from B in a way, that such credential is actually liable in B.

Lets extend existing showcase that utilises very straightforward one-attribute schema: `passed: boolean` with a product of an AI (i.e. ChatGPT4) that is a conjunction of multiple (at least two) governance frameworks. In other words showcase cross-governance use case.

Show case:
1. Create a prompt that teaches ChatGPT either about the spec of OCA (part of it is sufficient) or about OCAFile (later needs conversion from OCAFile into OCA Bundle).
2. Construct an (artificial?) governance framework A. Ensure framework contains an entity that is mappable into a schema. Also make sure the framework mentions capabilities, i.e. who can do what or who must do it and when.
3. Create OCA Bundle `O` out of the framework A.
4. Issue ACDC credential using `C` for a party `Z` (bundle must include attribute that would reflect as an identifier).
5. Try to find some legal law that would represent framework B.
6. Depending on what we'll find for `A` and `B`, either:
1. using A, B and ChatGPT, create a prompt that injects A, B and constructs a transformation from A to B.
2. using A, B and ChatGPT, create a prompt that injects A, B and constructs a joint framework out of it.
9. Within a service governed by `B`, enable `Z` to use his credential and authorize her to a service.

## Creation of Governance

Creation of Governance can involve:

- Board of Directors (A)
- Executive Management (B)
- Legal and Compliance Professionals (C)
- Internal Audit (D)
- Data Protection Officer (E)
- External Consultants (F)
- others (G)

Each of this actor provides own input into Gov Framework. To keep consistancy we leveraging LLM to collect input and split out ready to be signed Governance Framework (GovFr)

entity LLM
actor A
actor B
actor C
actor D
actor E
actor F
actor G
collections GovFr
A -> LLM
B -> LLM
C -> LLM
D -> LLM
E -> LLM
F -> LLM
G -> LLM
LLM -> GovFr : Approval process

## Execution of any action cross-governance

Assuming following example:

entity "IoT provider" as IoT
entity "Store owner" as S
entity "Service provider" as Se
entity "Security organization" as G

IoT -> Se: Inform about alarm
Se -> IoT: Confirm
IoT -> G: Ask to open the store
IoT -> S: Notify about intervention
Se -> G: Proof authority to enter the store and fix issue
IoT -> Se: Guide how to fix the issue (telemetry access)
Se -> IoT: Provide proof of work
IoT -> S: Provide proof of intervention

NOTE: keep in mind that IoT provider can be interaction with different equipment providers or multiple IoT providers could be within one building.

This is specific example of general problem in IoT space where multiple actors needs to coordinate to execute simple task of fixing/maintain specific device.

Following above example we having:

IoT provider (A)
Store owner (B)
Service Provider (C)
Security organization (D)

|Action|Involved Governance|
|------|-------------------|
|A<->C| A / C|
|A->D| A / B / D|
|A->B| A / B |
|C->D| A / B / C / D |

Example:
Opening hours changes from 8pm to 9pm, rule would be updated - information need to propagate through A / B / C / D since they need to adopt their actions according to the new rule.

Service Provider is changed - no need for new onboarding since the service provider would get proper credential to allow him to perform same tasks as previous one.

### Change of rule and it's propagation

collections GovFr as Gov



entity "IoT provider" as IoT
entity "Store owner" as S
entity "Service provider" as Se
entity "Security organization" as G


S -> Gov: Rule: New required attribute to be capture for work report
note left
Fulled by LLM interface
end note
IoT -> Gov: Request new schema for work report
IoT -> Se: inform about incident
Se -> IoT: provide updated work report

Se -> Gov: Rule feedback: Can't fill required field for type B devices as it does not exist
note left
Fulled by LLM interface
end note
Gov -> S: Request for review
S -> Gov: Rule: Update rule about option attribute for device type B
note left
Fulled by LLM interface
end note

### LLM support in governance framework construction vs. reinforcement learning with feedback loop for existing governance frameworks

There is subtle difference of how LLM supports governance creation and its various contributors (see above) and how it enables more flexible environment in all the edge cases of already existing governance framework.

Cross-governance creation with the LLM support involves feedback loops from humans. Execution of such framework and edge-cased adaptations (i.e. missing data but required by the framework) enables less-constrained or more flexible environment, where its dynamism is unpredictable. It is therefore feedback less and decided by the LLM how to overcome given edge case.