See comments and suggestion on the ToIP Technical Architecture Spec - Working Draft.
- Wenjing Chu went over the structure of the spec.
- The question of terminology definitions came up in depth
- Neil Thomson said that most of last week's APAC meeting was taken up by terminology discussions.
- Drummond Reed said the the Concepts and Terminology WG tooling for terms wikis would be perfect to use here. There was a general consensus that it was indeed a good tool, but in the short term the glossary definitions being created for this spec will go into a glossary at the end of the doc for now.
- ACTION: Neil Thomson will consolidate the terms being defined for purposes of this spec into a glossary at the end of the spec—or as a separate document.
- ACTION: Drummond Reed will work with the Concepts and Terminology WG members to set up a terms wiki for the Technology Stack WG that we can begin using immediately with this spec.
- Neil Thomson shared that "The key to security is verified trust. ToIP, SSI (and particularly KERI) provide verifiability by default, vs. by design or implementation."
- Wenjing Chu pointed out that all forms of trust are relative to some type of risk. You always have to take into account the context and the associated risk(s).
- Neil shared that "Certification/assertion builds on verifiability, which allows for alternate mechanisms for how to do that. But the requirements will be on the verifiability mechanism. If verifiability is not cryptographic based and executable without human intervention (autonomic verification), then it's unlikely to be reliable."
- Wenjing continued to go through the sections of the spec and the goals and open issues with each.
- The term “party" came up. It is a very well-defined term in the eSSIF-Lab glossary. https://essif-lab.github.io/framework/docs/terms/pattern-party-actor-action
- Vlad Zubenko asked whether there was a separation between hardware and software systems. Wenjing share that there was intentionally not a difference in the overall design; they are all treated as nodes participating in the overall system.
APAC MEETING
- We agree to spend the time going over Jo Spencer's comments since this is the first meeting he has been able to attend in person in quite a while (a testament to 18:00 PT being a much better time for the APAC meeting).
- Jo asked about vendor independence and the question of interoperability testing/certification.
- Wenjing pointed out that there can be different requirements for different layers for different ecosystems.
- Drummond asked about interoperability testing as a goal.
- Wenjing said that is covered in section 5.6. This spec is currently an architecture spec for which we do not expect interoperability testing to be done because it is either complete nor detailed enough for that purpose.
- Darrell said, "Perhaps we should state that for now we will not be moving towards a conformance regime, but that we may do so in the future."
- Drummond suggested that we should say someplace in this spec (probably in the Future Work section, but also possibly in the Introduction) that the TSWG expects to produce follow-on specifications that will be designed to support interoperability testing.
- sankarshan said, "That is fair. I'd like to see a future path being mentioned which would include testing/suites etc."
- Alex said, "I think we will move towards conformance criteria - for self-certification, but not an auditing/test-suite style conformance regime yet."
- Darrell responded, "Exactly - that we are on a path, but not going all the way with the first version."
- Neil responded, "@Sankarshan - on the path to test compliance is evidence at the spec/design level of compliance with the requirements. We need to make it easy for proposals for alternative tech to understand if they understand the requirements prior to committing to design/code/test Agreeing w Alex."
- Judith asked about which of our specs would be aimed at going to ISO.
- Wenjing said that this architecture spec could be able to go to ISO even as an architecture spec. It would typically be one of a suite of specs, with the others being more specific specs for implementation.
- Jo said that it would need considerable editing to become an ISO spec.
- Jo asked about Wenjing's use of the term "locus of control".
- Wenjing clarified that it is a bootstrap term about where the root of trust begins.
- Drummond asked whether we needed both "root of trust" and "locus of control".
- Wenjing gave a concrete example of a mobile wallet app that functions as the locus of control while the root of trust is the secure enclave in the mobile phone.
- Drummond agreed with that distinction between the terms:
- Root of trust deals with cryptographic primitives such as keys.
- Locus of control is the software that controls the use of those cryptographic primitives.
- Jo's next comment was a question about the use of "autonomous" identifiers vs. "autonomic" identifiers.
- Wenjing argued for the former term.
- Drummond suggested that both terms could be used, with "autonomic" identifiers being an even narrower definition of autonomous identifiers.
- Jo's final comment (that we had time for) was about "end systems". His comment was that they may not be "end" because they also may be consumed by other systems.
- Drummond suggested that this is the system that is at the "end" of an application of the "End-to-End Principle".
- Jo was fine with calling it an End System if that definition of the system serving as an endpoint in one of the ToIP protocols.