2022-06-30 TATF Meeting Notes

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.

@Daniel Bachenheimer just presented on part of a panel at London Identity Week. The panel was hosted by Nick Mothershaw of Open Identity Exchange. The panel focused on the common themes for how to move digital identity and digital wallets forward.
- Dan had a side meeting with Singapore's gov tech team that was very interested in trust frameworks.
- ISO SC-17 is working on travel documents and SC-10 is mDL. Dan is suggesting that they look at a common, broader standard on personal identity documents.
- @Tim Bouma met with UK DCMS this week and feels there's going to be movement forward on some common views. He suggested it would be good to meet with DanB regarding progress at ISO.
@Drummond Reed share the W3C announcement of the approval of the W3C Decentralized Identifiers (DIDs) 1.0 spec. The press release is slated for later in July.
@thomsona asked whether the scope of the TATF included authentication; if so, should we include consideration of FIDO2 passkeys, of which there was a great deal of focus at Identiverse last week.
- @Wenjing Chu said that it would definitely be a consideration in our architecture work. He made two points:
  - In the TSWG meeting on Monday, the FIDO2 protocol was discussed, and we definitely want to include it in our scope.
  - The other consideration was that passkey sync was being handled by the OS platform vendors; it is not a FIDO2 standard.
  - Tim brought up that there are other options for cross-device authentication.
  - @Daniel Bachenheimer pointed out that the European Digital Identity Wallets initiative is broader than FIDO, which is specific to edge authentication. This was a consideration in the KTDI work that Accenture did with the Netherlands. So our architecture should be more generic.
  - Allan felt that authentication needed to happen at Layer 2. The spec should include that.
  - @Drummond Reed agreed with Allan that ToIP authentication architecture should be broader than passkey.

APAC:

@Neil Thomson said his view of authentication is that it is necessary to establish identity, and that may not be entirely at Layer 2 if it needs to include identity binding.
@Jo Spencer said that authentication may be needed at different layers because you are authenticating different assertions at different layers.
@Darrell O'Donnell agreed that the term "authentication" is not specific enough to be very helpful. Communication between DIDs (DIDComm) is an "authenticated" channel, but it is not "authentication"
@Jo Spencer said that the separation of the layers is most helpful in this respect.
@Drummond Reed agreed that identity binding (to a human) is not a Layer 2 action, but a Layer 3 action.
@Wenjing Chu said that the interactions at Layer 2 establishes authentication at the transport channel layer. He pointed out that with KERI, the cryptographic trust is all put in the identifier and the cryptographic proofs associated with that identifier.

5 min

Review of previous action items

Chairs

@Wenjing Chu said that he is trying to capture the roughly five major use cases.
@Drummond Reed agreed and said that he would review that section of the spec and propose if it is missing any use cases he considers "canonical".
@Jo Spencer said that he would also review that section.

ACTION: @Wenjing Chu to add a new GitHub issue to propose the terms agreed to on this call: "Endpoint System", "Intermediary System", and "Supporting System".

This was revised in the Google doc except for the diagrams.

We had a discussion about the application of the End-to-End Principle.

ACTION: @thomsona to propose a new term.

ACTION: @Wenjing Chu to add a new GitHub issue to propose the rational for why the spec needs Intermediary Systems by including references to DIDCOMM V2 - https://didcomm.org/book/v2/routing and Web5 node - https://identity.foundation/decentralized-web-node/spec/

30 mins

Spec progress and issues

@Wenjing Chu

Discussion of progress on the working draft of the ToIP Technical Architecture Spec and outstanding issues.

DECISION: We will deliver a first Public Review Draft by Thursday 8 Sept 2022 in order to present it at the Hyperledger Global Forum in Dublin beginning Sept 12. We will also try to complete the majority of the work of having a complete draft by the end of July so we can work (possibly largely asynchronously) on issues in August.
- Wenjing pointed out that we will need to pick up the pace on the spec if we are going to meet that deadline. This means we'll need to work at resolving the comments that we have first. He doesn't want to add new content if there is not yet agreement over current content.
- Drummond said he intended to lean into editing and issues management in July.
- @Vladimir Zubenko asked about issues management.
- Wenjing said that we need to start posting more and working through them.
Allan pointed out that it is not yet a spec that can be directly implemented; it is an architecture spec. So it's important to set the audience and the scope.
- @Vladimir Simjanoski felt that a strong scope statement will help us close a bunch of open issues. It will also be very useful as an educational.
ACTION: @thomsona and @Drummond Reed to draft an Audience and Scope section that clarifies that the ToIP Technology Architecture Specification is a higher-level architecture spec that is not intended to be detailed enough to write implementation test suites against.
- Wenjing felt this spec can help make it clear what the purpose of the document is in terms of limiting interoperability choices, including guidance to protocol designers.
- @Tim Bouma pointed out that four layer models are well established, but we need to get down to more specifics of the boundaries of the layers.

APAC:

@Wenjing Chu has not closed a few of the largest remaining comments because they affect the overall structure and content of the spec.
- SCOPE -
  - If we Agree - get it written; If we don't - then what?
- AUDIENCE -
  - If we Agree - get it written; If we don't - then what?
  - How deep does this go - it's aimed to describe broad cases, the layers and interactions. It does not hold opinions on specific implementations.
- PHILISOPHIC -
Wenjing used the example of IETF specs. They are often broken into separate documents. One specifies the overall architecture and components. Then separate specifications are written for each protocol or interface between components.
- The architecture spec also lays out terminology and use cases and names the requirements for layers.
- @Neil Thomson said the the first group that needs consensus on scope is this TF. We also need consensus on the canonical use cases — and to be specific about what use cases are out of scope.
Darrell said that this document is more descriptive than prescriptive.
@Neil Thomson : "Defining sufficient details write test suites (which has been asked for) - is clearly out of scope."
We discussed the detailed diagram contributed by @thomsona and agreed that it went to a level of detail that was more appropriate for an interoperability test case specification than for a high-level architecture specification. So we propose to move it to one of the more detailed specs to follow the architecture spec.
Wenjing said that many of the other comments have to do with discussions of terminology.
- Jo agreed and said that as long as Wenjing was using terminology consistently throughout the spec, he was okay.

10 mins

Plan for transition to GitHub in July

@Wenjing Chu @Darrell O'Donnell @Drummond Reed

We had set the end of June for all submissions to the Google doc. What is our full plan for transitioning to GitHub?

Our plan is going to be to start opening any major "directional" issue on GitHub so we start driving those to closure.
DECISION: Starting next week, we will spend the majority of each weekly meeting on issue resolution AND we will be driving issues to be closed asynchronously both in the Google Doc and in Github. We will work minor issues in Google doc (and slowly wind those down) and major issues will be in GitHub.

5 mins

Review decisions/action items
Planning for next meeting

Chairs

Next week's call will focus on closing on the Audience and Scope section, and then identifying any other issues affecting the overall structure of the spec.

Meeting Date & Time

Zoom Meeting Recordings

Attendees

Main Goals of this Meeting

Agenda Items and Notes (including all relevant links)

Decisions

Action Items

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. @Daniel Bachenheimer just presented on part of a panel at London Identity Week. The panel was hosted by Nick Mothershaw of Open Identity Exchange. The panel focused on the common themes for how to move digital identity and digital wallets forward. Dan had a side meeting with Singapore's gov tech team that was very interested in trust frameworks. ISO SC-17 is working on travel documents and SC-10 is mDL. Dan is suggesting that they look at a common, broader standard on personal identity documents. @Tim Bouma met with UK DCMS this week and feels there's going to be movement forward on some common views. He suggested it would be good to meet with DanB regarding progress at ISO. @Drummond Reed share the W3C announcement of the approval of the W3C Decentralized Identifiers (DIDs) 1.0 spec. The press release is slated for later in July. @thomsona asked whether the scope of the TATF included authentication; if so, should we include consideration of FIDO2 passkeys, of which there was a great deal of focus at Identiverse last week. @Wenjing Chu said that it would definitely be a consideration in our architecture work. He made two points: In the TSWG meeting on Monday, the FIDO2 protocol was discussed, and we definitely want to include it in our scope. The other consideration was that passkey sync was being handled by the OS platform vendors; it is not a FIDO2 standard. Tim brought up that there are other options for cross-device authentication. @Daniel Bachenheimer pointed out that the European Digital Identity Wallets initiative is broader than FIDO, which is specific to edge authentication. This was a consideration in the KTDI work that Accenture did with the Netherlands. So our architecture should be more generic. Allan felt that authentication needed to happen at Layer 2. The spec should include that. @Drummond Reed agreed with Allan that ToIP authentication architecture should be broader than passkey. APAC: @Neil Thomson said his view of authentication is that it is necessary to establish identity, and that may not be entirely at Layer 2 if it needs to include identity binding. @Jo Spencer said that authentication may be needed at different layers because you are authenticating different assertions at different layers. @Darrell O'Donnell agreed that the term "authentication" is not specific enough to be very helpful. Communication between DIDs (DIDComm) is an "authenticated" channel, but it is not "authentication" @Jo Spencer said that the separation of the layers is most helpful in this respect. @Drummond Reed agreed that identity binding (to a human) is not a Layer 2 action, but a Layer 3 action. @Wenjing Chu said that the interactions at Layer 2 establishes authentication at the transport channel layer. He pointed out that with KERI, the cryptographic trust is all put in the identifier and the cryptographic proofs associated with that identifier.
5 min	Review of previous action items	Chairs	ACTION: All members of the Technology Architecture TF to add their proposed use cases to the Google doc as soon as possible. ACTION: @Tim Bouma and @Drummond Reed to prepare a proposed name and scope for this "policymaker" deliverable (@thomsona's suggestion is "ToIP Technology Introduction for Policymakers") and document this in a wiki page for next week's meeting. Tim has been working on an early version as a Google doc that outlines the basic ideas for policymakers. ACTION: @Neil Thomson to proceed with initial population of the TSWG terms wiki with assistance from @Drummond Reed. @Drummond Reed will pass that on to the CTWG. ACTION: @Drummond Reed to schedule @Kaliya Young for our June 30th meeting to speak on her perspective that the ToIP stack is very "Hyperledger Aries architecture focused" and thus not friendly to other "stacks". @Darrell O'Donnell said he knows of a stack that will be able to pass the Hyperledger Aries test suite, but is not the Hyperledger Aries stack. Thus we can break the dependency between the two. @Alex Tweeddale was interested in that because Cheqd is working on decoupling Anoncreds from Aries from Indy. ACTION: @Kevin Griffin to assist @Wenjing Chu check into the issue with the TechArch repo not rendering the ToIP stack graphic. ACTION: @Neil Thomson to add text to the Motivations and Use Cases section to explicitly talk about what is out-of-scope. @Wenjing Chu said that he is trying to capture the roughly five major use cases. @Drummond Reed agreed and said that he would review that section of the spec and propose if it is missing any use cases he considers "canonical". @Jo Spencer said that he would also review that section. ACTION: @Wenjing Chu to add a new GitHub issue to propose the terms agreed to on this call: "Endpoint System", "Intermediary System", and "Supporting System". This was revised in the Google doc except for the diagrams. We had a discussion about the application of the End-to-End Principle. ACTION: @thomsona to propose a new term. ACTION: @Wenjing Chu to add a new GitHub issue to propose the rational for why the spec needs Intermediary Systems by including references to DIDCOMM V2 - https://didcomm.org/book/v2/routing and Web5 node - https://identity.foundation/decentralized-web-node/spec/
30 mins	Spec progress and issues	@Wenjing Chu	Discussion of progress on the working draft of the ToIP Technical Architecture Spec and outstanding issues. DECISION: We will deliver a first Public Review Draft by Thursday 8 Sept 2022 in order to present it at the Hyperledger Global Forum in Dublin beginning Sept 12. We will also try to complete the majority of the work of having a complete draft by the end of July so we can work (possibly largely asynchronously) on issues in August. Wenjing pointed out that we will need to pick up the pace on the spec if we are going to meet that deadline. This means we'll need to work at resolving the comments that we have first. He doesn't want to add new content if there is not yet agreement over current content. Drummond said he intended to lean into editing and issues management in July. @Vladimir Zubenko asked about issues management. Wenjing said that we need to start posting more and working through them. Allan pointed out that it is not yet a spec that can be directly implemented; it is an architecture spec. So it's important to set the audience and the scope. @Vladimir Simjanoski felt that a strong scope statement will help us close a bunch of open issues. It will also be very useful as an educational. ACTION: @thomsona and @Drummond Reed to draft an Audience and Scope section that clarifies that the ToIP Technology Architecture Specification is a higher-level architecture spec that is not intended to be detailed enough to write implementation test suites against. Wenjing felt this spec can help make it clear what the purpose of the document is in terms of limiting interoperability choices, including guidance to protocol designers. @Tim Bouma pointed out that four layer models are well established, but we need to get down to more specifics of the boundaries of the layers. APAC: @Wenjing Chu has not closed a few of the largest remaining comments because they affect the overall structure and content of the spec. SCOPE - If we Agree - get it written; If we don't - then what? AUDIENCE - If we Agree - get it written; If we don't - then what? How deep does this go - it's aimed to describe broad cases, the layers and interactions. It does not hold opinions on specific implementations. PHILISOPHIC - Wenjing used the example of IETF specs. They are often broken into separate documents. One specifies the overall architecture and components. Then separate specifications are written for each protocol or interface between components. The architecture spec also lays out terminology and use cases and names the requirements for layers. @Neil Thomson said the the first group that needs consensus on scope is this TF. We also need consensus on the canonical use cases — and to be specific about what use cases are out of scope. Darrell said that this document is more descriptive than prescriptive. @Neil Thomson : "Defining sufficient details write test suites (which has been asked for) - is clearly out of scope." We discussed the detailed diagram contributed by @thomsona and agreed that it went to a level of detail that was more appropriate for an interoperability test case specification than for a high-level architecture specification. So we propose to move it to one of the more detailed specs to follow the architecture spec. Wenjing said that many of the other comments have to do with discussions of terminology. Jo agreed and said that as long as Wenjing was using terminology consistently throughout the spec, he was okay.
10 mins	Plan for transition to GitHub in July	@Wenjing Chu @Darrell O'Donnell @Drummond Reed	We had set the end of June for all submissions to the Google doc. What is our full plan for transitioning to GitHub? Our plan is going to be to start opening any major "directional" issue on GitHub so we start driving those to closure. DECISION: Starting next week, we will spend the majority of each weekly meeting on issue resolution AND we will be driving issues to be closed asynchronously both in the Google Doc and in Github. We will work minor issues in Google doc (and slowly wind those down) and major issues will be in GitHub.
5 mins	Review decisions/action items Planning for next meeting	Chairs	Next week's call will focus on closing on the Audience and Scope section, and then identifying any other issues affecting the overall structure of the spec.