• Start recording
• Welcome & antitrust notice
• Introduction of new members
• Agenda review

• 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:

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

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…