Updates of general interest to TATF members.

• Drummond Reed shared that the ToIP session at the European Identity Conference was very successful as the EU digital identity community is "starved" for interoperability solutions.
  • Judith also noticed how much others at EIC were using our terms but not following our design principles. She feels we should be holding others accountable for using the language of ToIP and SSI without actually walking the walk.
  • Darrell asked for advice about how we should best encourage others to use the language. Judith suggested that we start but just asking questions, and then pointing out where there are differences with our terminology and design principles.
  • Judith also shared that she appeared on the final closing panel on GAIN (the Global Assured Identity Network) in order to share our message about how decentralized identity interop should work—without endorsing the pure OIDC federation model currently in the GAIN white paper.
  • Jo also pointed out how we can always press of interoperability and how it is being handled—anyone who is creating a walled garden solution will find it hard to justify vs. the open ToIP model.
  • A wonderful meme that emerged is "OIDC within the enterprise, ToIP across the Internet."
• Rodolfo Miranda shared that the DIF DIDComm Working Group will vote on the DIDComm V2 specification next Monday.
• Judith Fleenor provided an update on the latest meeting with OIX and Nick Mothershaw about the mapping of the ToIP / SSI model to the OIX "DigitalID" model. Judith and Daniel Bachenheimer attended and worked out the final images of the mapping that will be published in their OIX Trust Framework 2.0 Guide and a blog post prior to Identiverse.
  • Judith also said that OIX has started a working group on trust frameworks for decentralized identity, so if there are ToIP members who want to be at that table, now is the time.
  • Alex Tweeddale mentioned that both he and Ankur Banerjee, who were both working for IDWorks in London at the time, were working on a decentralized identity trust framework at OIX some time ago.
• Jo Spencer shared that Sezoo is working on a project with the government of New South Wales and they are very aligned with ToIP—so his work here is more relevant than ever.
• Judith Fleenor also mentioned that Bill Bell, from the government of Western Australia, has joined.

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.
    • Companion Google Doc created which allows suggested edits/comments on Terms - ToIP Technology Architecture Specification - (Working) Glossary
  • 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
• Vladimir 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.

Agenda items for the next meeting:

• thomsona will present on use cases.
• We also need to have a discussion about moving the draft over from Google docs to GitHub so we can begin using GitHub issues for issue management.
• ACTION: Drummond Reed to add two items to next week's agenda: 1) thomsona presenting on use cases, 2) Moving the spec from Google docs to GitHub.