...
Time | Agenda Item | Lead | Notes |
3 min |
| Chairs |
|
5 min | Announcements | All | Updates of general interest to TATF members. |
2 min | Review of previous action items | Chairs | The notes from the previous meeting (2022-08-03) were not clear about explicit action items.
|
ToIP Technology Architecture Spec Topics | Discussion of progress on the working draft of the ToIP Technology Architecture Specification: | ||
15 mins | Additional diagrams | Drummond Reed | From Darrell O'Donnell in the TSWG Slack channel: I won’t likely make the Thursday meeting. Business has me messing with too much of the time I am supposed to be spending with friends that flew in from out of town.I suggest reviewing the two slides here: https://docs.google.com/presentation/d/1skHbfJqXaX8er8iUzisNWWnFCMp7bv2ZjKmsq4GXyeA/edit#slide=id.gf9dcc57430_0_4
Discussion: First slide could be updated with a vertical side bar that crosses layers for common ToIP support components used by all layers. Scott Perry - need to get more detail. Registries are confusing as they are also needed at layer 4. Replace "registries" with "resolver(s)". Trust spanning is perhaps the right term - suggest interop layer Allan Thomson - need the sidebar for common ToIP components/services. The world hasn't moved to DIDCOMM - what are the preferred protocols and channels for Layer 2. Change this to a set of (Interop) requirements for which DIDComm is the ToIP contribution. Need a diagram version that maps to OIDC (to provide a (conceptual) bridge) Tim Bouma - commenting to DIDComm as being a "heavy" solution to interop communications. There are several specs that are provided as "full-featured", which may be overkill for initial implementation and acceptance (and actually required functionality). Decentralized identifiers, and Verifiable Credentials) are other examples. The trend has been to "overspecify". Drummond Reed - we don't want DIDComm as the only tech/spec for achieving the "trust spanning" communication protocol. Neil Thomson - that suggests we want to specifications for each layer expressed as requirements, not solutions and certainly not specific technologies. Drummond Reed agreed with Neil — we need to be designing the right architecture and designing component specifications to meet those requirements. Tim Bouma agreed that it is the need for a trust spanning pprotocol (or "hourglass protocol") that will "capture the imagination" and gain the focus we need to complete the work. If we put that in place, "today we don't think about how we're communicating; tomorrow you won't have to think about how your connection is trusted". |
10 mins | Requirements numbering and appendix | Drummond Reed | The notes of the last meeting indicated a discussion of an approach where all normative requirements are numbered throughout the spec and then compiled in a table in an appendix. Darrell O'Donnell and Drummond Reed discussed this when Drummond returned from vacation and before Darrell left on vacation. PROPOSED DECISION: We will number all normative requirements and compile them into a table in an appendix, including cross-links in both directions. |
10 mins | Mental model of system types | Drummond was on vacation for the last two meetings but saw the notes from the last meeting including the discussion of the mental model of system types. This appeared helpful but still appears to have some issues. Can we close completely on definitions of:
| |
10 mins | Next steps on the Working Draft | Drummond Reed | With Darrell O'Donnell and Wenjing Chu both out on vacation this week and next, Drummond proposes to:
|
5 mins |
| Chairs |
...