Meeting Date

  •  

Recording

  • This meeting was not recorded (operator error). Future meetings should be set to auto-record (see the Action Items).

Attendees

Main Goal of this Meeting

Updates on task force progress.

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: None.
30 minsTF UpdatesTF Leads

Interoperability TF

  • Richard Esplin (Director of Product at Evernym) was not able to attend the meeting, but had communicated to Drummond Reed that the work on the SaturnV TIP (ToIP Interoperability Profile) has largely finished. So the remaining members of the Interoperability TF recommend that the TF either be closed down or rededicated to working with the DIF Interop WG.
  • Darrell O'Donnell explained that he is going to start attending the DIF Interop WG meetings to discuss working together on interop testing.

Trust Registry TF 

  • Darrell O'Donnell reported that this work is moving nicely. The TF is going to stick with the name Trust Registry Protocol and limit the scope of V1 to query operations.
  • The focus in on finishing the basic ability to query for the status of an issuer, verifier, or another trust registry.
  • There is discussion about also being able to return the history of an entry for an issuer, verifier, or trust registry because the history can send important signals about trusting that entity.
  • Daniel Bachenheimer shared that the history issue is important because a querier could query multiple trust registries to determine the level of trust in a particular entry.
  • Darrell pointed out that the complexity begins to grow very quickly when additional considerations or requirements are put on the trust registry, so we are trying to keep the scope of V1 very tight.
  • We also discussed that revocation of a trust registry entry is different than the revocation of credentials issued by that issuer. Keeping the two separate is important.
  • Sam pointed out that GLEIF has had a similar question come up with the GLEIF ecosystem governance framework (EGF), under which GLEIF authorizes issuers of a credential called a vLEI. That issuer is called a vLEI issuer. If a vLEI issuer is revoked, the vLEI issuer cannot revoke credentials (i.e., the credentials become "zombie" credentials). The solution was for the GLEIF EGF to establish a grace period for vLEI credentials during which the credential is still valid so that the holder of the vLEI credential can find a new vLEI issuer.
  • Daniel Bachenheimer noted that the "zombie" credentials may still be trusted in other ecosystems because the issuer revoking from one ecosystem is not necessarily transitive. There are two layers of trust:
    • Trust in the issuer.
    • Trust in the credential not being revoked by the issuer.
    • Samuel Smith pointed out the situation that creates "zombie credentials" is when the reason for revoking trust is that the issuer has lost trust, but the holder has not. This matters within an ecosystem, but may not matter across ecosystems depending on the other ecosystem's policies.
  • Drummond Reed noted that the GLEIF EGF work should consider support for the TR Protocol.
  • He also noted that the GCCN (Global COVID Credentials Network) hosted by LF Public Health is a very eager customer for the TR Protocol.
  • Jim St.Clair noted that the discussions of revocation here is more robust than what is currently begin discussed in the W3C Credentials Community Group (CCG) and their work on an VC HTTP API.
  • Samuel Smith pointed out that if credentials are not automatically expired in an explicit period of time, then the problem of "zombie credentials" must be solved by the ecosystem. The challenge that the W3C CCG community is facing is that there are different models for privacy-preserving credentials.
  • Daniel Bachenheimer pointed out that the way the verifiable data registries work, the issuer can continue to revoke an issued credential. Samuel Smith explained that with ACDC, credentials can be chained, so trust in the credential is chained to higher-level credentials.

ACDC TF

  • Samuel Smith said the current focus is refining the spec. All ACDC spec work is Apache 2 licensed.
  • ACDC uses KERI DIDs, so there is a dependency on the KERI spec.
  • ACDC credentials use immutable schemas with self-addressing identifiers (SAIDs). A SAID is a content-addressable identifier that is bound to and embedded in the schema and the credential that uses it.
  • ACDC credentials use plain JSON and schemas use JSON Schema.
  • ACDC does not yet have a design for privacy-preserving credentials. The current default is to use the Indy/Aries Anoncreds approach.
  • Drummond Reed noted that the ACDC requirements are being fed into the work going into preparing a charter for the next version of the Verifiable Credentials WG charter at W3C.

Design Principles TF

  • Drummond Reed reported that the Community Writing Workshops on the Design Principles for the ToIP Stack are going very well.
  • Last week there was a fantastic presentation on the Laws of Trust that featured work by Mary Lacity and her associates at the University of Arkansas. This has resulted in the "trust principles" expanding from four to six, which now build on each other in a nice logical progression.
  • Writeups on the other "structural principles" is also proceeding nicely, with full writeups submitted for the End-to-End Principle, Connectivity is its Own Reward, and Cryptographic Verifiability.
  • Drummond anticipates that a complete first draft will be ready by roughly the first week of September.
  • All members of the TSWG are encouraged to participate, even if just reviewing and commenting.
5 mins
  • Review decisions/action items
  • Planning for next meeting 
Chairs

ACTION: Darrell O'Donnell to set up the Zoom calendar invite for this meeting to auto-record.

Decisions

  • None

Action Items

  • ACTION: Darrell O'Donnell to set up the Zoom calendar invite for this meeting to auto-record.


  • No labels