AtalaPrism / Ahau call | 2023-11-03

What do we want out this meeting?

Ahau

Is AtalaPrism interested in having a committed long term relationship with Ahau
- i.e. ongoing co-design, we commit to you, you commit to us
Will you ever support
- the SDK to Issue / Verify?
- multi-controller DIDs
  - https://www.w3.org/TR/did-core/#multiple-did-controllers
What can we expect as the results of this feedback (what's your process)?
- Esteban:
  - feedback loop process involves periodic review, which we use to inform decisions about e.g. processes/ feedback
  - e.g. improving documentation
  - Mix: request - can you tell us what was useful, when you act on something?

AtalaPrism

Our cultural Context

Our context as a 'collective of collectives' is important for understanding our answers:

Āhau is (p2p), like a federated system. Clusters of peers making up communities at different scales (p4p).

Common scales of organising in Te Ao Māori (the Māori world):

Whānau - close and/or extended family, maybe you and all your cousins
Hapū - a collection of whānau
Papa Hapū - related Hapū
Iwi - a collection of Hapū (post colonial construct)
Trusts – whānau and/or Hapū connected through economic centres often connected to whenua (land)

Here are some ways we think groups may use Verifiable Credentials (VCs):

To prove identity across groups (where membership is a type of identity)
- Examples
  - proving my membership in my whānau (family) when recording my whakapapa (genealogy / history)
  - proving my membership in a Hapū (connections wider than my immediate family) when registering with my Hapū / Papa Hapū / Iwi
  - proving my membership in an iwi (collection of hapū within a specific region of Aotearoa, New Zealand)
To prove entitlement to tribal benefits and services
- Tribal health services, education scholarships
To prove entitlement to Government services for Māori
- Māori health services, Māori land court, Waitangi Tribunal
- Tax department, Pensions, …
A group member using VCs which prove Hapū / Papa Hapū / Iwi / Trust membership as a form of identity with a Government institution
- We're early in the process of establishing conditions / rules for Hapū / Papa Hapū / Iwi becoming state accredited sources of identity working with The Crown, via NZ Government – Department of Internal Affairs
A group member opens a new bank account, and uses their VCs as proof of identity
- banks, universities, health, etc

We are early in the process of establishing which hypothesised use-cases will be the most valuable.

It is still early in the life of Ahau too - communities are still discovering the tools, transitioning traditional identity and governance methods to the digital realm and organising around how they use it, so we're not yet sure what the predominant uses will look like in the long run.

Some early work as part of the TribalDIDs project (useful for context: https://miro.com/app/board/uXjVMXMGrAo=/)

Āhau is local-first software

No spinners: your work at your fingertips
Your work is not trapped on one device (resilience)
The network is optional
Seamless collaboration with your colleagues
The Long Now
Security and privacy by default
You retain ultimate ownership and control
Source is open (to ensure auditability, and maintenance)
Pluralism first" (Data is inherently polycentric - no single source of truth, truth emerges between)
Everything has a whakapapa (genealogy / history)

Esteban's questions

User base estimation

Ahau is currently preparing for the deployment of Ahau mobile designed for tribal members, with Digital Identity available as a beta service. The different tribal groups currently using Ahau vary widely in "membership" (from 500 - 50,000) so these figure could change drastically should a tribe (new or current) decide to fully deploy digital identity to support membership operations.

The current estmations have been made based on one of our tribal partners and current digital identity project partner.

1. How many users of the solution will be issuers?

For groups that want to issue credentials, there will be ≥ 1 issuers. Most likely 2-8.

We don't know how many groups will want VCs yet.

This will depend heavily on the UX/UI, co-design, what needs it is able to serve, how people react to the dynamics of it, and how hard it is to set up (including the CDD processes / automoation of same).

The current setup of AtalaPrism will require them each to run a server, or find collection of groups with enough shared trust that they could set-up multi-tenancy.

2. How many users of the solution will be holders?

For every group that issues VCs, every member will be a holder.

A group might be 150 to 5000 people.

We imagine that groups that do use VCs, they will likely be larger (as there will be some overhead estabilishing accreditation with identity verifiers and Banks/ Government etc. Cost of running infrastructure will be key determiner.

3. How many users of the solution will be verifiers?

Initial 2-8 verifiers as apart of the pilot project.

There will be as many potential verifiers as there are groups

anyone using a VC from one group to register with another (as a sort of reference check)
anyone using a VC with Govt/ Bank/ University/ Healthcare System…

Issuance of Credentials

4. Issuance Process: Can you describe the process of how and when credentials will be issued?

When a person joins a group, they will automatically be issued (and automatically accept a membership VC). This works because we already have a "registration" process for groups (more like "understanding deeply how / whether you're related" to strengthen relationships, demonstrate whakapapa / connection to land / group affected by theft of whenua. There will be many more groups who will be doing something like KYC (Iwi and Trusts particularly).

Please see this diagram for more information

5. Frequency: How often are credentials issued?

Each time:

a person joins a group
the details of the membership claim change in some way

6. Reissuance: Do credentials need to be reissued on a regular basis?

Not that we think at this stage, but could be in the future as the credential schema adapts.

Many holders will connect / whakapapa to multiple different whānau (families), hapū or iwi. This may require credentials to be 'reissued' to include multiple connections that have been updated based on one holders whakapapa (particularly as adoption grows)

7. Bulk Issuance: Will there be instances where a large number of credentials need to be issued quickly?

Not for our intial deployment, but possible to handle future use cases.

Likely that for a whanau / hapū group that sets itself up as a VC issuer, then the issuance will be happening one at a time, at the speed that a human can approve registrations. This could be registration approved (1 VC issued) per day, or if the person has researched / corroborated 20 people they may want to "bulk issue" for those 20 … or wait veeeeeryyy patiently for our automated process to run it's course (the mediator is slow)

In the case that a group of 1000 people retrospectively decides to be a VC issuer, we may need to be able to issue 1000 VCs within a reasonably time-frame. People are patient, but if it's slow (1 issue at a time), then that means we have to build more crash-resistence, which is costly (engineer time, maintenance).

Examples:

Whānau / Hapū / Iwi have a reunion, this could be a situation of bulk issuance of <1000 VCs being issued.
Groups operating economic centres with existing shareholder registries which relate to connections with whenua (land blocks) and cross many hapū (but don't necessarily include all members of a hapū) will likely bulk register at AGM-like hui (meetings). Bulk issuance of >1000 VCs.

Verification of Credentials

8. Verification Process: Can you describe the process of how and when credentials will be verified?

I apply to join a group, and as part of my registration present my VC from another group which may recognise it.

Have already listed the possible entities we think could be "groups".

9. Frequency: How often are credentials verified?

At least once per holder, our current use case is supporting sub-tribes to provide proof of with membership entitlement for the "parent-tribe".

Past this, we believe it will be more depending on the different services that incorporate this. Use cases will include gaining access to 'resourses' of many different kinds. Data, information, knowledge… could be in the form of art, live biodiversity data…

10. Bulk Verification: Will there be instances where a large number of credentials need to be verified quickly?

It is highly likely yes.
However, we don't know yet until people use the system.

Credential Complexity

Our prototype is currently a claim which is something like:

{
  tribe: {
    tribeId: String,
    tribeName: String
  },
  person: {
    legalName: String,
    dateOfBirth: String
  }
}

11. Detail Level: Do the credentials contain basic details like name and date of birth or more extensive information?

Yes to "basic details" - we're starting simple. We don't know what richness / more complexity could offer us yet. Honestly we've been focusing on getting the data flowing. The content hasn't had much exploration yet.

12. Data Length: Do any fields on the credential contain long strings of data, such as profiles or resumes?

Not yet. We can imagine wanting that, but again we'll know more once communities use it and start imagining and requesting new functionality. We think even basic functionality could be hugely transformative though - Indigenous Infrastructure which interoperates with Aotearoa's current institutions, helping grow the Māori Economy.

13. Complexity: Are the credentials composed of many complex parts?

We don't know yet. Likely use cases will become more complex as use cases expand, regenerative finance and multi-capital accounting is developed further with partners in our ecosystem

14. Credential Use: How will credentials be used in proofs?

Shared membership
People who are holding an issued credential by a recognised/trusted tribe, are also entitled as members of another tribe

15. Selective Disclosure: Is selective disclosure required when using multiple credentials together?

Technically this is required as apart of the New Zealand governement digital identity trust framework. If use cases develop with government requiring the framework adoption (which is our intention).

So yes, likely, but still to be explored.

16. Privacy: Is a privacy-preserving proof required?

Likely but still to be explored by our team.

Show and Tell

show Āhau
show whakapapa
show our automated flow
we are many
- not running people through a singular service like "ahau.com" (walled garden)
- more like a federated platform

What we've enjoyed

Open source!
Test-net easy to get going on
Tutorials/ Guides/ APIs have decent coverage
- still room to improve, but have answered most of our questions really well
Responsiveness of the AtalaPrism team

Āhau's Challenges So Far

Webhooks didn't really help
- we want kaitiaki (~admins) to be sent a signal… but kaitiaki are all p2p and an http endpoint doesn't suit that
- we do have some http accessible relays (Pataka) which could pass messages into our p2p messaging layer… this feels like another http/p2p problem
Holder only SDK
- it's bizare having to use an HTTP endpoint as an issuer when we have devices which have unique cryptographic keys and signing capabilities as a base layer in Ahau
- ideally the SDK would be a full agent that could also Issue and Verify
- we think there's a spec which describes how such a thing could be done
Mediator Speed
- one action consistently blocks our flow for 5 seconds
- we literally poll the APIs to see if the state is ready to progress
  - NOTE: we have automated a lot of the issuance steps, because of the aforementioned registration process we already have in place
Double Mediator
- we already have a mediator, it's strange feeling to be using another one from another system
- e.g. establishing a "connection" is not something we need to worry about in Ahau as we have already established that securely by other means. We initially tried to seperate out the messages from the transport in AtalaPrism and just use Scuttlebutt (ssb), but that was too hard (docs and code didn't make extracting DIDComm/messaging part easy? We likely still need it for Verifying, but maybe not also?)

How could the system better fit use case

We will attempt to add more here in the coming weeks.