Agenda:
- reflections:
- what have we learnt?
- what don't we know?
- what questions do we need to ask?
- personal reflection
- where are we?
- revisit our goals
- where are we going next
- is there anything we're supposed to complete?

---

## Reflections

### what have we learnt?

AtalaPrism infra:

#### 1. SDK (atala-prism-wallet-sdk-ts)
- for mobile/ thin client
- considered an "EdgeAgent" - some functionality of "FullAgent" but not all
- the "Holder" agent only
- designed to not be always-online
- communicates / coordinates via always-online Mediator
- used:
- not at all
- tried to use this but didn't have methods we wanted, our 1st prototype ended up only using API. This is probably guided only used APIs... and we couldn't get it working easily with the SDK
- Francisco Javier Labrador:
> You would use the sdks to accept, receive and store a credential, to establish new connections with PrismAgents, mediators, and also to answer to verification requests when the verifier asks to

#### 2. Mediator
- role:
- always online message relay
- connection bridge from e.g. holder <--> issuer
- used:
- did we use this?
- we used this with the SDK to set up messaging yes
- we used a provided mediatorDID.. don't know where or what this was
- maybe a mediator "hosted by RootsID - a project"
- for our prototype, we ended up not using the mediator to instead use the API ... do those use a mediator under the hood

#### 3. PrismAgent
- role:
- issuer
- verifier
- holder (but light version of the agent)
- used:
- used API provided in our [Ahau POC](https://gitlab.com/ahau/ahau/-/tree/enable-credentials)
- in API form is:
- an always online agent
- CRUD on : connections/ offers/ credentials/ proofs/ schemas/ DIDs
- assumption:
- designed to be used on a per user basis
- can be an issuer, holder, verifier... but we don't want everyone to have access to that
- problem?: all things are available on prism agent. But we don't want Holders to have access to other peoples DiDs/ Credentials
- at the moment we communicate with a PrismAgent "holder" API, but we need one holder per person
- with current setup any holder can see all held things?

### what don't we know?

- we don't understand where the "keys" are stored
- does the PrismAgent-as-API:
- behave as a Mediator?
- use a common Mediator?
- do the 3 apis you gave us use the same Mediator?
- we don't know how to run the API ourselves yet

- how to do use VCs yet
- how is the proof executed?
- is it auto-magic sugar?

- how heavy is the "light" client on mobile?

### personal reflections:

- Mix:
- was confused and annoyed the SDK was not a fully functional Agent?
- we have a secure offline-first messaging + storage layer in ssb already, but were unable to extract the messages easily from the atala setup. Felt locked in
- the tools seem really tightly coupled

- Ben:
- the tests helped a lot with
- some docs were good, but there were gaps which made understanding hard
- the SDK alone does not serve our Ahau use case. We expect our app users to perform multiple roles/ functions:
- be a holder
- be a issuer
- be a verifier

### Where are we

We have a prototype
Still need to do VC presentation/proof

Project requirements:
- community pilot in a production env:
- [ ] tribe can issue a credential
- [ ] another tribe / entity can verify a credential

Aim to have this done by end of October

## Revist our goals

1. Tribes should be able to issue tribal-member credentials
2. Members should be able to use this verify their membership
- a) with tribe for other services/ activities tribe provides
- b) register with other tribes that are also using Ahau
- this is people using ahau software, are replicating with group?
- c) with a 3rd party
- NOTE: only this case requires a global registry/ lookup

### Ahau context

- use of DIDs + VCs is exploratory
- can this create value for indigenous/ tribal communities?
- we want to minimise the specialised infrastructure required to maintain
- Pataka setup (relay into ssb)
- Static IP address
- Port forwarding
- one application
- NOTES:
- the pataka is a "dumb message relay" which supports known peers, there is nothing special about it (dumb in that it doesn't speak ... much)
- you can have multiple pataka
- pataka are specific to particular communities, not global services

Use VCs to verify to someone that I am in a tribe

## What do we need Atala/Cardano for?

1. publishing globally accessible DID documents
- a unique ID
- a document which contains:
- public keys for verifying signatures
- (public keys to encrypt things to?)
- instructions for how to
- form a connection with me
- (issue offers to me?)
- (issue credentials to me?)

2. mediator
- communicating offline
- communicating between unconnected peers
- SSB already does this tho?
- SSB passes too much info (whole log) on connection
- SSB doesn't work for verification for people outside of connection range
- (by default pataka only support friends and friends-of-friends to communicat: a.k.a. 2 hops)

## Where to next?

1. adding VC presentation
2. changing parts which can't be API
- holder should not be an API?