Versions Compared

Old Version 3

changes.mady.by.user thomsona

Saved on

compared with

New Version 4

changes.mady.by.user Neil Thomson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

APAC Meeting

...

TimeAgenda ItemLeadNotes
3 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 minAnnouncementsAllUpdates of general interest to TATF members.
2 minReview of previous action itemsChairs
  •  ACTION: If you have any feedback on issues #40, #46 & #49 — roles, pull requests (PRs) and the version publication process — please go in and comment. If you have any questions, ask them in the #tswg-tech-arch-tf Slack channel.
  •  ACTION: ALL TATF members need to read the EasyCLA process document and decide on the CLA manager assignment for your organization in order to continue to make contributions to the TAS. You can also set it up to provide wildcard support for all representatives of your org (based on your email domain). See Elisa Trevino for access/help.
  •  ACTION: Darrell O'Donnell to propose another variant of Figure 4 as a candidate for the "full stack" diagram discussed in issue #31. DONE.
  •  ACTION: thomsona to propose a simpler diagram to replace the current Figure 4 in section 6.2 as discussed in issue #31.
  •  ACTION: Jo Spencer to noodle on some diagrams that more clearly define the borders of the "sphere of influence" of the ToIP stack.
  •  ACTION: Drummond Reed to begin a draft of a blog post announcing release of the Public Review Draft of the TAS.

ToIP Technology Architecture Specification Review Topics

Discussion of progress on the working draft of the ToIP Technology Architecture Specification (TAS). Links to relevant documents and diagrams:

5 minEasyCLA Process
Drummond Reed 
It's easy! Read the EasyCLA Guide and follow it.
5 minIssue #44 and PR #50 — License File
Antti Kettunen 

Antti's PR is stuck on a DCO problem.

Can we close the issue?

 

Antti said the PR is now #52. The DCO issue is an attestation from the developer. Antti has made an issue assigned to Elisa.

We then discussed the actual license that we need to attach. For copyright, it is Text is CC-BY-SA-4.0.

This is all in our WG charter; we can just copy it from there. The other source would be the Good Health Pass.

Judith: "Once EasyCLA is fully implemented you can most likely turn off DCO.  DCO was turned on because we didn't have EasyCLA in place yet."

ACTION: Drummond Reed will close on this with Scott Nicholas.

5 minsClosing PR #49 — PR Contribution Process

Andor Antti Kettunen 

Two of the four assigned editors have approved this PR. Can we merge it?

Description: Initial governance files of CODEOWNERS, CONTRIBUTING.md, and GOVERNANCE.md. Related to issues:

#40
#39
#38
#46

Antti believes this is ready to merge; Andor agrees. 

DECISION: PR #49 was labelled as last call.

10 minsIssue #31 — Four Layer Diagram

thomsona Drummond Reed Darrell O'Donnell Jo Spencer 

Review Allan's proposed new version of Figure 4.

See this evolution of the previous version.

Allan presented a new diagram (see screenshot #1 below) as a model diagram to convey the key concepts of what is in and out of scope for ToIP. He also showed Jo Spencer 's diagram that conveys many of the same concepts.

Darrell liked Allan's diagram for how it communicates the big picture.

Wenjing Chu likes Allan's diagram but said that Figure 4 is the scope of just a single Endpoint System.

Jacques Latour likes the diagram but feels it is still too high-level for his own purposes, which need to get into lower-level systems such as DNS. Allan agreed that the model diagram could be more detailed and specific, with a more detailed diagram.

Comments:

  • Darrell: yup - kind of a "why are we here" and "how do we fit into the world" - very crucial for those that haven't mixed and drank the koolaid.
  • Judith: Or use the HourGlass, and then have the other one in an appendix, for more information.
  • Tim Bouma : I am always on the lookout for a simple unifying theme for the ToIP model: So far (stealing Drummond's words), this model enables "Trust at a Distance" (TaaD)
  • Darrell: These diagrams can fit in to the TAS as well as be used in blogs and other marketing/communication material that we use for very pointed purposes.
  • Andor: I think the abstractions are super helpful, but also would be helpful I think to ground the abstraction in an actual example. I think that could be helpful for people to understand.
  • Darrell: I suggest Drummond takes the action of assembling these diagrams (views) into a story and we move on.
  • Neil: +1 to Allan's comment - these are diagrams for the architects, not policy makers.
  • Wenjing: the main point is the hourglass shape.
  • Andor: it would be helpful to take an example use case and run all the way through it.

ACTION: Drummond Reed to propose a structure for a storyline that provides that storyline.

15 minsIssue #10: Definition of "authenticity" (is "integrity" needed?)

Neil Thomson 
Drummond Reed 

Neil will update us on his work on this issue — see this Google doc.

Neil explained that there are different definitions of these terms, and they are usually specific to particular contexts. He has also been talking to Henk van Cann about the same issues with related to KERI and ACDC.

Drummond had a long talk with Sam Smith and wrote up the following:

This paragraph in Neil’s writeup goes to the heart of it:

Dan Bachenheimer points out that many readers with security backgrounds will expect to see integrity listed alongside authenticity because they are considered separate security properties. For example, a message could have been sent by an authentic sender, but tampered with in transit so its integrity is lost.

Sam’s first point was very simple: if the message was “tampered with it transit”, then it is no longer from the authentic sender. At that point it is from the attacker (who of course will endeaver to make it the message still look like it is from the authentic sender).

Sam put it to me this way:

There is no concept of data transmission over the Internet where you can establish the authenticity of the data — secure attribution to a source — without having confirmed the integrity of the data.

So the resolution seems simple: the definition of “authenticity” when it comes to the ToIP stack and the Layer 2 Trust Spanning Protocol can essentially be:

A communication is authentic at ToIP Layer 2 when the receiver can cryptographically verify that it has been digitally signed by the private key bound to the sender’s identifier. Because this form of authenticity is conveyed via a digital signature over a body of content, by definition that digital signature is only valid if the body of content has not been tampered with in transmission. Therefore this form of authenticity inherently includes integrity.

If we agree on this point, then all we need to discuss is the PR that is needed to actually close the issue.

  • Darrell asked whether this point isn't actually self-evident.
  • Wenjing explained that he and Sam Smith had an hour-long discussion about why "integrity" is inherent in the way we are looking at "authenticity". That discussion agreed that one part is about the "integrity" of the party sending the message, i.e., identity binding. The other perspective is message authenticity and integrity, which are inextricably bound.
  • Wenjing suggested that we can address this in a footnote or a separate paragraph.
  • Neil T. - That Sam/Wenjing hour discussion is recorded and transcribed - available on Hackmd.io - will move that over to the terms wiki.


10 minsTrust Registry

Darrell O'Donnell 

Key efforts beginning on the Trust Registry Protocol Specification v2.0. 

  • Key items for consideration:
    • Trust Registry metadata (avoiding standard "devops" things.
    • Credential Types (we reference the idea in v1.0 but don't discuss it further).
    • Presentation (Proof) Request Types.
    • Verifier and Issuer "types".
    • DID Method support (i.e. which ones are / are not supported).
    • Interop Profiles that are required/optional.
    • What Wallets are supported.
    • Role of DNS as anchor point.
    • Machine Readable Governance.
  • ACTION: Darrell to create document (Google Slides) to begin collaboration (in the ToIP Google Drive)
5 mins
  • Review decisions/action items
  • Planning for next meeting 
Chairs

Screenshots/Diagrams (numbered for reference in notes above)

#1

Image Added

Decisions

  • Sample Decision Item

...