Time

Agenda Item

Lead

Notes

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:

5 min

Announcements

All

Updates of general interest to TATF members.

• @Judith Fleenor (Deactivated) announced that she testified before the State of California in favor of the California Trust Framework, a bill (CA SB 1190) being discussed to support official educational credentials as verifiable credentials in California as a project of the California Dept of Technology. It was only a two minute testimony opportunity, but it was successful in the committee unanimously passing a vote to advance the bill to the next committee (the Education Committee), who will consider it on the April 20th.

  • Judith explained that additional letters of support can be submitted for the next hearing. Letter can be addressed to the chair, Senator Connie Leyva, via https://calegislation.lc.ca.gov/Advocates/faces/uploadfile1.xhtml

• @Vikas Malhotra shared that the IEEE Working Group,  Cybersecurity for Next Generation Connectivity Systems, that he had shown us a proposal for several months ago has now been approved and is up and running. It currently has 12 members. It is an open group; anyone can join: https://standards.ieee.org/industry-connections/cyber-security-for-next-generation-connectivity-systems/. 

• @Drummond Reed shared that a new consortia has formed in the EU to bid for one of the eIDAS 2.0 grants. https://eudiwalletconsortium.org/

• @Judith Fleenor (Deactivated) said the the Utility Foundry WG is ready for final comments on several of their new deliverables; keep a watch out for those.

5 min

Review of previous action items

Chairs

15 mins

The KERI / ACDC "stack"

@Philip Feairheller

Per the first action item above, Phil shared a diagram (screenshot #1 below) of how all the component pieces/specs for KERI and ACDC fit within the four-layer ToIP stack. (This diagram is now part of the ToIP Protocol Stack Diagrams Google Slides deck.)

• The basic layer is the cryptographic "primitives" that are used by the higher layers.

• The second layer is the connection layer, where a KERI controller connects to other systems, especially witness and watcher networks.

  • It also defines the ACDC credential format.

  • The PTEL is a log of all the credential-related events.

• At layer 3, higher-level protocols can be composed using a series of EXN (extension) messages. KERI and ACDC do not define those; that would be part of other work.

• The same is true for Layer 2.

• @Darrell O'Donnell asked about the role of SADs and SAIDs (SAD = Self-Addressed Data. SAID = Self-Addressing IDentifier). Phil explained that those identifiers and data structures provide the digests that link together schemas and messages and also to chain credentials together.

• Darrell also asked if all the pieces must be used together or whether the can be decomposed and used independently.

• @Antti Kettunen asked "In Keri, How would one define external APIs that hold additional information regarding the did subject. Such as what ToIP Trust registry spec defines using services in a did doc."

  • Phil answered that one would create a message type that can communicate with those APIs.

• @Tim Bouma commented that he very much liked fitting the KERI and ACDC components into the four layers. 

• Others on the call were also highly appreciative as it helped them understand where the pieces of KERI and ACDC "fit".

• @Drummond Reed suggested it might make a good presentation at the upcoming Internet Identity Workshop.

• In the afternoon APAC meeting @Sam Smith @Wenjing Chureviewed and discussed on Phil's layering diagram shared in the morning:

  • @Sam Smithnoted that some of the components currently shown in separate layers will need to be combined together to achieve trust goals and commented on a few examples. So these layering lines can be more complex. Also noted other adjustments might be sensible.

  • @Wenjing Chu commented that, from establishing a universal spanning layer point of view, all components needed to establish an identity, should be in the connection layer (i.e. layer 2). He described an approach of defining layer 1 as "infrastructure" only by moving most of the primitives in layer 1 to layer 2, and simplify layer 2 to basic ID and connectability only. Others would be in layer 3. Sam liked the idea but more discussion with the larger group is needed.

  • Ask @Drummond Reed @Darrell O'Donnellto add to next week's call 2 topics:

    • @Sam Smith: ask to add chained root of trust  (?)topic to agenda

    • Repeat the above discussion next week when more are in attendance.

ACTION: @Drummond Reedto add chained root of trust topic to the agenda for next week's calls.

ACTION: @Drummond Reed to add spanning layer discussion to the agenda for next week's calls.

15 mins

FIDO white paper discussion

@Drummond Reed
@Wenjing Chu

Continue a discussion that started on the ToIP Slack about the recent FIDO white paper. @Wenjing Chu posted this:

There’s a lot to learn here. I’d like to highlight one - we need a proper mental road map for the development of a complex ToIP stack. AKA a life cycle model.  Reactionary mode can be exciting but ultimately not most productive.

• Wenjing thought that the paper did a good job describing the problem they were trying to solve: using FIDO "passkeys" and authenticators across multiple devices.

• @Drummond Reed noted that the paper addresses several deficiencies in FIDO, including device recovery and multi-device synchronization, that were holding back broader adoption.

• It reminded Wenjing that, while we are making rapid progress is defining the stack, it can help to focus on the overall lifecycle of the ToIP stack and our expectations for the evolution of the stack.

• For example, are we pushing for an MVP of the ToIP stack quickly, and then expecting to revise it based on subsequent market/adoption feedback?

• So Wenjing suggests that we should see if we have consensus on a roadmap about how we expect the ToIP stack spec to evolve.

• Drummond suggested that we should probably include such an overall description of scope and expectations in the ToIP Technology Architecture Specification document.

• Wenjing suggested that if we state the use cases for which we are explicitly trying to solve in the first version, this will help us determine scope and give us a bound for the first version.

• Drummond, Darrell, and Kevin all voiced support for this approach.

DECISION: The TATF shall develop a roadmap for the evolution of the ToIP stack, a summary of which should be included as a section in the ToIP Technology Architecture Specification V1, in order to make it clear what are the canonical use cases and scope limitations for the V1 ToIP stack.

ACTION: @Drummond Reed to make the first agenda item for next week's meeting a discussion of the canonical use cases and scope limitations for the V1 ToIP stack.

ACTION: @Drummond Reed to start a discussion on our Slack channel about the canonical use cases and scope limitations for the V1 ToIP stack in preparation for next week's meeting.

20 mins

Continue review of comments on requirements

All

Continue our review of requirements in the storyline deck of layer-by-layer requirements. Our goal is to move into drafting the Google doc version of the spec next week. (All slide numbers are of 2022-03-31).

• We ran out of time for this agenda item. However Drummond agreed to the following action item:

ACTION: @Drummond Reed to prepare a revised outline of the Google doc version of the ToIP Technology Architecture Specification for review at next week's meeting.

5 mins

• Review decisions/action items

• Planning for next meeting 

Chairs