Samuel Smith Kent Bull Henk van Cann Kevin Griffin Ruth Choueka P Subrahmanyam Mark Scott Nuttawut Kongsuwan Rodolfo Miranda Joseph Lee Hunsaker Trent Larson Michal Pietrus
Agenda
- Announcements
Reports implementation of ACDCs
- vLEI
- Cardano?
- Provenant
- ECR Provenant issues
- Slack channel vLEI
- Schema
- vLEI EGF Issues
- action to add or decide on repot to host vLEI EGF issues Kevin Griffin
- Community support from Henk to help with vLEI issues EGF
- need more of a How To with vLEI EDF
- Pending updates to Schema vLEI to add change required fields
- ViRA
- GS1
- HCF
Items
- ToIP ACDC Meeting Recordings are not available until 4 weeks after meeting. Need more timely availability.
- Kevin Griffin action item need to talk to ToIP automate
- GLEIF Root-of-Official-Trust well known structure and formation details
- GLEIF RoOT comprised of seven individuals and five "escrowed" participants used in creation of a multisig AID.
- Uses establishment only events
- Escrow participants are used in the eventuality that the root participants are unavailable (a designated survivor situation)
- Establishment only means has no non-establishment events: https://github.com/trustoverip/acdc/wiki/non-establishment-event
- GLEIF then created two additional multisig AIDs "Internal" and "External"
- GLEIF RoOT then approved delegation of the internal and external AIDs, this delegation adds the first link in the chain of authority being established.
- The "External" AID is how GLEIF manages its interactions with pending and existing QVIs (https://github.com/trustoverip/acdc/wiki/qualified-vlei-issuer)
- This multisig AID is then used to issue the Qualified vLEI Issuer vLEI Credential to a QVI that has completed the GLEIF qualification process.
- The Internal AID is how GLEIF acts as a Legal Entity in the vLEI ecosystem.
- GLEIF RoOT comprised of seven individuals and five "escrowed" participants used in creation of a multisig AID.
- vLEI Schema Versioning EGF Doc: https://github.com/WebOfTrust/vLEI/blob/dev/docs/Schema_Registry.md
When the version of the schema changes the SAID of the schema will change. A new credential based on the new scheme, will be a different credential (because the semantics might have changed) ... An old credential based on an old schema (version) will still validate. "Do I enforce the latest version of a schema for all the credentials or just their own version at the time of issuance?" → This has become a business logic decision.
- We don't have to have a protection against mutable schemas, like access control, because every mutated schema will lead to a new credential.
GLEIF decides what goes into a vLEI; this is a governance design decision. So other identifier systems might have different governance designs; e.g. a committee voting on what goes into a vLEI-like data structure.