2023.06.13 APAC IGRTF Meeting Notes
Recording
Attendees
Jo Spencer, John Phillips, Neil Thomson
Presentation/Slides
John Phillips: Towards a mental model for governance - link
Main Goal of this Meeting
- Delegated/Proxy Issuers (continuation of prev APAC call discussion - May 30, 2023
- Issuers just Issue - need to separate Issuer support functionality and extensions to other components
- Lifetime of Credentials, including volatility
Agenda Items and Notes (including all relevant links)
Time | Agenda Item | Lead | Notes |
5 min |
| Chairs |
|
20 mins | Delegated Issuers | All | Delegated Issuers may play a key role in resolving interop issues between VC Issuers, particularly where existing non-electronic credential issuers are looking to have an integrated use of VCs across a number of services (e.g., the Australian government of New South Wales Issuing Service which is acting on behalf of multiple government agencies. A possible solution is to have an Issuer sign the delegated Issuer to indicate the delegated Issuer is providing an (Issuer) approved level of providing VC credential claim and other information/data mapping. An unresolved issue is handling updates to “source data” that was used to qualify a VC for a subject (e.g., driver’s license) for a person. This includes revocation of dependent VCs, change in data (e.g., legal name change), plus VC version updates, etc. A particular problem is finding all cases where the VC is in use (e.g., cached by a Verifier) and resolving changes without unnecessarily breaking transactions. How will re-issuance and revocation be handled - requirements for this have not been defined. As the Guardianship/Dependent relationship investigations have illustrated, relationships between trusted parties and provenance must be carefully considered (lots of use cases), including where each of the Issuer, Proxy Issuer, Holder and Verifier may be in different jurisdictions. A proxy issuer needs to be trustable by both the Holder and the Verifier Questions on Issuers, requirements and how they fit into the overall ecosystem
Any transformation that is done on a VC (or any data) is going require that a log of the transformations be captured (for non-repudiation purposes). Likely the transform recipient will also need to receive the original (VC), the transformed and a log. Note that these could be by reference vs. a need to copy the information. In any transaction where a VC is exchanged, is a copy the VC sent or is it a reference to the VC (e.g., a single copy, possibly cached in a few places)? |
Issuers just Issue | Issuers just Issue
Where does the business logic go (Issuer, Holder, Verifier, all of the above?) is governance the way to control business logic vs. technical solutions (e.g., ZKPs)? Is the solution to let the Verifier do what ever it wants with the data restricted by governance vs. technical solutions? The next challenge is to take John (Phillip's) document "Towards a Mental Model of Governance in ToIP" and apply it to Issuer, Holder, Verifier, Trust Registry (with Issuer first) | ||
Lifetime of Credentials | Lifetime of Credentials is critical, including volatility - this suggests that either credentials can be upgradeable (via transforms) and re-issued or that older formats must be supported for a long time (or that re-issuance to newer formats is baked into the overall system).
Next steps are use cases of typical and stress scenarios, models and resulting requirements… |
Screenshots/Diagrams (numbered for reference in notes above)
For Universal Credential Adapters and Use of Intermediaries Discussion
Decisions
- Sample Decision Item
Action Items
- Sample Action Item