2023.06.13 APAC IGRTF Meeting Notes

Recording

  • Recording link:
    • Start of session: 7:46
  • Full-Text Transcript: link

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)

TimeAgenda ItemLeadNotes
5 min
  • Start recording
  • Welcome & antitrust notice
  • Introduction of new members
  • Agenda review
Chairs
  • Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
  • New Members:
20 minsDelegated IssuersAll 

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

  • How governance of an Issuer (and its evaluation criteria for issuing a VC) differ from the authority that “certifies” the Issuer? 
  • And what higher authority governs the Issuer-Issuer/certifier? 
  • What does the overall Issuer structure fit into the Ecosystem
  • How similar different are the operations of the Entity/Authority of an Issuer of certified plumber certificates differ from the Trust Registry evaluator/verifier that includes subjects in an industry-specific context registry?
    • Is it only a matter of different rule sets?
    • Do they each need levels of assurance (e.g., a common pattern for doing evaluation/verification)?

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

  • Do Issuers do operations and lifecycle management of what they Issue?
  • Under what umbrella to Issuer services (e.g., revocation management?) operate?
  • Is multiple presentations of a VC/data an Issuer responsibility (no?)

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). 

  • What is are the longer term maintenance responsibilities of an Issuer, particularly for volatile credentials (e.g., ones that can be invalidated or downgraded for fairly frequent circumstances)?
    • Example: professional certifications - plumbers, arborists (renew chain saw safety every 2 years). A key case raised by job work site credentials, where an individual industrial worker may have 20 or 30 licenses with annual or bi-annual renewal

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