Versions Compared

Key

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

...

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

Zoom Meeting

...

Recording

...

Attendees

NA/EU:

Image Removed

APAC:


APAC:

  • NOT HELD THIS WEEK

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: none.
2 minReview of previous action itemsLeads
10 minsOpenID4VC High Assurance Interoperability ProfileAll

The OpenID Foundation has published OpenID4VC High Assurance Interoperability Profile with SD-JWT VC. Jo Spencer has suggested  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 minsZero-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.

Also worth discussing what bearing it might have on our workWe 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 minsWorking Draft ReviewWenjing Chu 

Provided Wenjing is able to attend (he's at a Linux Foundation event in Shanghai), we will 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 about what to acceptfor 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 ITEM: Drummond Reed to start a Github discussion on the VID appraisability framework in section 2.1.5.

ACTION: ALL TSPTF MEMBERS review the minutes Github discussion once posted and decide if you want to volunteer to contribute to the VID appraisability framework in section 2.1.5. 

Wenjing next went into section 3 on Messages . See (see screenshot #5. That's the whole next section). 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 that use case in the next section on nestingthe 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
  • Review decisions/action items
  • Planning for next meeting 
Leads

Screenshots/Diagrams (numbered for reference in notes above)

#1

...

#2

...

#3

...

#4

...

#5

#6

#7

Decisions

  • Sample Decision ItemNone

Action Items

  •  Sample Action Item

  •  

    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.