You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

Meeting Date & Time

This is a special meeting of the ToIP Trust Spanning Protocol Task Force in order to have a deep-dive workshop to begin the consolidation stage of our work on the trust spanning protocol.

See the Calendar of ToIP Meetings for exact meeting dates, times and Zoom links.

Zoom Meeting Links / Recordings

  • <to be added when the meeting is over>

Attendees

Agenda Items and Notes (including all relevant links)

TimeAgenda ItemLeadNotes
3 min
  • Start recording
  • Welcome & antitrust notice
  • New member introductions
  • Agenda review
Leads
  • 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:
30 minsReview of the ToIP Technology Architecture Specification V1.0Wenjing Chu Wenjing reviewed the key points of the TAS as they bear on the design of the TSP, including screenshots #1, #2, and #3 below. He clarified that the TSP is the protocol that connects any two ToIP Endpoints.
90 minsOpen DiscussionAll

Daniel Hardman The opening topic he proposed, using screenshot #4 to highlight the specific TAS requirement (L2.9), to what extent do we want the TSP to be descriptive or prescriptive.

  • Descriptive would allow the parties using the TSP to describe their trust basis such that they can decide whether to trust each other.
  • Prescriptive would specify that certain types of trust guarantees are required.

Wenjing Chu proposed that the TSP protocol itself should be descriptive, but that the ToIP stack as a whole can be prescriptive.

Oskar van Deventer asked for more clarification of what the question means.

Daniel Hardman gave the example of whether the TSP should require VIDs (most descriptive), DIDs (more prescriptive), or AIDs (most prescriptive).

Oskar van Deventer wanted to be sure that implementations are interoperable.

Samuel Smith primary concern is that the security of the higher layers depends on the security of the lower layers, so if the lower layer is weak, you can't fix it at a higher layer.

Drummond Reed asked the question: can the strength of the security at the ToIP layer be selected by the ToIP endpoints involved as part of their governance frameworks or security policies?

Wenjing Chu believes the benefits of providing a wider set of connectivity options. 

Willem de Kok said that the lower level of trust you put in the system, that is likely to become the lowest common denominator that the system normalizes on.

Bree-Ana Blazicevic: the TSP is the most vital for establishing the "gold standard", and ToIP should be the gold standard.

Samuel Smith To support multiple levels of trust, it must be appraisable by the user, and the user must be able to have control of those. As long as they have an appraisable trust basis that can be communicated to an end-user.

Daniel Hardman understands what Wenjing said that higher-level layers can help with trust, but Sam's concern is that the trust basis must be established at a lower layer. However it is important that individual persons must have the ability to decide about the trust level they are willing to accept — but users are not equipped to make those decisions.

Wenjing Chu The key is verifiability. If the TSP layer guarantees authenticity — and we do that by defining how verifiability is achieved — we can be in the same camp. Two other quick points:

  • There is no "gold standard" of trust. Security is not a one-dimensional thing. It is n-dimensional. You can be very strong in one sense and very weak in another. There also can be tradeoffs between security and privacy (though that is not always true). So we want to be sure that users who want strong security guarantees of different types have a way to achieve this.
  • Wenjing feels that you almost all trust tasks will use another layer over the TSP protocol.

Neil Thomson is this a problem that ToIP needs to solve? He used an example of data privacy. If the leap is too high, adoption won't happen. But if we have a "ladder", folks can slowly climb it.

Samuel Smith If we define "verifiability" to include "appraisability of the trust basis", then he is in agreement with Wenjing.

Drummond Reed said that "appraisability" may in fact be a new requirement that we didn't capture in the TAS yet. He'd prefer that vs. trying to "stuff it" into "verifiability".

Daniel Bachenheimer used the FIDO protocol as an example of how, by deciding on how to describe the assurance factors, the verifier can apply their own policy against that info.

Drummond Reed agreed and said that he's working on similar descriptive claims for identity assurance.

Wenjing Chu said that he supports appraisability as a factor that could be incorporated into the TSP.

Daniel Hardman shared that "appraisability" could be a solution here but his biggest concern is how we can precisely define that.

Jo Spencer was also in favor of this solution, and said that each party to a communication should be able to decide about the levels of trust needed for different communications and trust tasks. He also said that there will likely be standard profiles created that enable such.

Drummond Reed mentioned that providing more descriptive information about the policies and procedures implemented by any actor in a ToIP trust community  both sides of the stack __________

Samuel Smith explained the different types of trust basis and said that we could make it very simple or very complex. We need to be careful about how complex we make it.

Drummond Reed used the example of the step-up from HTTP to HTTPS as the only consumer-level signals providing "appraisability". Initially, only a small subset of websites added support for HTTPS. But as security issues on the Web got worse, the whole Web upgraded — to the point where Google will not serve up a website that does not use HTTPS. That changed the whole security landscape.

https://trustedcomputinggroup.org/wp-content/uploads/TCG_DICE_Attestation_Architecture_r22_02dec2020.pdf


5 mins
  • Review decisions/action items
  • Planning for next TSP Workshop
Leads

Screenshots/Diagrams (numbered for reference in notes above)

#1


#2


#3


#4


Decisions

  • Sample Decision Item

Action Items

  • Sample Action Item


  • No labels