Meeting Date & Time
This Task Force meets every Wednesday. There are two meetings to serve different time zones:
- NA/EU meeting: 08:00-09:00 PT / 15:00-16:00 UTC
- APAC meeting: 18:00-19:00 PT / 01:00-02:00 UTC
See the Calendar of ToIP Meetings for exact meeting dates, times and Zoom links.
Zoom Meeting Recording
- NA/EU Meeting: https://zoom.us/rec/share/lppzEoGvSseVgTdsJTkuzwNfeotm_Rah20gGQ-mo8wd0y_oysanwLkZKwqd5IxCK.pchDfaSOpCnDAX9x
- APAC Meeting: NOT HELD THIS WEEK
Attendees
NA/EU:
- Drummond Reed
- Wenjing Chu
- Sam Smith
- Darrell O'Donnell
- Antti Kettunen
- Tim Bouma
- Christine Martin
- Daniel Bachenheimer
- Lance Byrd
- mathieu
- Matteo Midena
- Keerthi Thomas
- Steven Milstein
- Matteo Midena
APAC:
- NOT HELD THIS WEEK
Agenda Items and Notes (including all relevant links)
Time | Agenda Item | Lead | Notes |
3 min |
| Leads |
|
2 min | Review of previous action items | Leads |
|
10 mins | OpenID4VC High Assurance Interoperability Profile | All | The OpenID Foundation has published OpenID4VC High Assurance Interoperability Profile with SD-JWT VC. Jo Spencer suggested we review this to see what bearing it might have on our work. We agreed that it was relevant from the standpoint of trying to achieve some of the higher trust objectives of the ToIP stack, but of course it only does so in the context of VC issuance and presentation. It has limited relevance to the full breadth of the ToIP stack. |
10 mins | Zero-Trust Packet Routing (ZPR) | All | From the ZPR.org website (first spotted by Darrell O'Donnell): Zero-trust Packet Routing (ZPR) is a new approach to network security that enables enterprises to enforce security policies uniformly across all their systems and users. ZPR does this by creating an identity-aware network security layer, called a ZPRnet. It can work in the cloud, on premises, and in distributed environments, bringing the promise of fully authenticated network communications into dense multi-tenant environments. We discussed that this approach, which resembles VPNs and IPsec. The key difference is that it operates at the IP packet level and not at the level of establishing identity, authenticity, confidentiality between the parties operating the endpoints. It also does not address correlation privacy at all. |
30 mins | Working Draft Review | Wenjing Chu | Wenjing lead us on a review more of the Working Draft. See screenshots #1-#5 below. The section 2.1.5 is where we need to do the work to describe appraisability of a VID. Sam Smith: The OIDC and ISO mDL specifications have some assumptions related to PKI and key verification. It needs to be in scope for our TSP spec. Both of those specs are not built on the basis of assuming decentralized PKI. Wenjing's drafting assumes in section 2.2 that the spec will provide examples of how specific DID or VID methods can meet the requirements stated in section 2.1. Tim Bouma shared his view of the different approaches for DIDs and VIDs and the process of verifying them. He also compared them to UUIDs and the benefits they provide. Wenjing also suggested that timing and duration of a VID can be a factor. Sam Smith pointed out that native KERI AIDs are not technically DIDs. So it is up to us to say in the spec that it does not have to be a DID. Sam Curren has suggested in the past that we only use DID syntax. Sam wants to keep the VID types constrained. His proposal is to constrain the qualified VID types and put the burden on new types to be registered. Tim Bouma advocated putting the decision about what VIDs to accept on the governing bodies for ToIP-based digital trust ecosystems. Wenjing's thinking is that the appraisal framework simply provides a set of inputs to a policy engine. Darrell O'Donnell agrees with Tim's concern that we don't want to specifically exclude specific DID methods, but we do need to figure out a standard way to describe them. ACTION: Drummond Reed to start a Github discussion on the VID appraisability framework in section 2.1.5. ACTION: ALL TSPTF MEMBERS review the Github discussion once posted and decide if you want to contribute to the VID appraisability framework in section 2.1.5. Wenjing next went into section 3 on Messages (see screenshot #5). This section will cover the definition of messages and their required and optional properties. Sam Smith asked if a specific pattern is supported: applying a source signature on the plain text first, because that is the way to make it legally valid. ESSR does not cover that use case. ACTION: Wenjing Chu, in the subsection of Messages on nesting, to include the pattern of applying a source signature on the plain text first, before nesting, in order to support that requirement for legally valid digital signatures in certain jurisdictions. |
5 mins |
| Leads |
Screenshots/Diagrams (numbered for reference in notes above)
#1
#2
#3
#4
#5
Decisions
- None
Action Items
ACTION: Drummond Reed to start a Github discussion on the VID appraisability framework in section 2.1.5.
ACTION: ALL TSPTF MEMBERS review the Github discussion once posted and decide if you want to contribute to the VID appraisability framework in section 2.1.5.
- ACTION: Wenjing Chu, in the subsection of Messages on nesting, to include the pattern of applying a source signature on the plain text first, before nesting, in order to support that requirement for legally valid digital signatures in certain jurisdictions.