Introductions of TSPTF Members

[dhh1128]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[talltree]

I love the idea of those of us participating in the TSPTF using this thread to give a brief intro so others on the task force know a little about us and why we are here.

Myself, I helped get the ToIP Foundation started in 2020 and have been a member of the Steering Committee from then on. At that time I was Chief Trust Officer of Evernym, which was then acquired by Avast in late 2021, and Avast then merged with NortonLifeLock in Sept 2022 to form Gen Digital. So I'm now Director, Trust Services at Gen.

From 2020 thru 2022, I co-chaired the ToIP Governance Stack Working Group with @ScottPerryCPA. I then switched and now co-chair the Technology Stack Working Group with @darrellodonnell. I have also co-chaired the Concepts and Terminology Working Group since its start in late 2020 with @RieksJ (Rieks Joosten) (and in the early days @dhh1128).

Besides concepts and terminology (and trust architecture in general), I have a passion for identifier architecture (strange, I know) and spent seven years taking what is now the W3C Decentralized Identifiers (DIDs) 1.0 spec from the first draft to a full W3C Recommendation.

I'm also a co-author (along with 54 other contributors) to the book Self-Sovereign Identity (Manning, 2021).

I'm particularly excited about the Trust Spanning Protocol Task Force because I believe the trust spanning protocol is the keystone to the ToIP stack just the way the IP protocol was the keystone to the TCP/IP stack.

[JoOnGT]

I'm particularly delighted to be involved in the TSPTF. The TOIP Technical Architecture Specification provided a view of the critical thinking around the dependency of coordinated and aligned interactions for the purpose of driving interoperability between solutions. This will be the greatest challenge to the promotion and adoption of decentralised interactions and the decentralised evolution of ecosystems that they support.

The TSPTF can leverage experienced designers and thinkers with such different backgrounds, that I'd suggest the development of a logical model to which proposals can be applied and assessed. This model should be able to consider end point and connectivity establishment, interactions, operations and change (the whole lifecycle) of the Trust Spanning Protocol.

My background is in the design and implementation of mission critical, real-time payments systems the world over, but now I'm delighted to be working in advisory/consulting activities in and around Australia, for Sezoo.

[Willem-de-kok]

Hi, my name is Willem de Kok and I work at TNO. Within TNO we look into privacy routing and how this can be improved. As such I am also involved with DIF-DIDcomm.
I would like to be participate in the TSPTF, because I think that a good formulation of the requirements could enable large-scale interoperability and because the formulation of the requirements is related to the security/privacy solutions/claims that are possible within the world of SSI.

[Oskar-van-Deventer]

Hi, I am Oskar van Deventer, a colleague of Willem at TNO, a Netherlands national research institute. Adding to Willem's introduction, we are focusing on the "telco" view, as many of our customers are in the telco domain. So we will be exploring the potential role of telco's in providing "TSP Services", which may correspond to function of Intermediary Systems and Supporting Systems. The rationale for our focus is that telco's are highly trusted in many parts of the world, often even more than banks. This means that it will be important to give the TSP work a telco perspective, get telco's involved and make links with e.g. ETSI, ITU-T and 3GPP to get the TSP protocol adopted/endorsed for "trust services" in their specifications, perhaps similarly how 3GPP adopted the IETF SIP protocol for "voice-over-IP services".

[talltree]

@Oskar-van-Deventer: I'm thrilled to have the "telco" view strongly represented as I agree with you that it makes every bit as much sense for telcos to offer "TSP Services" (or you could generalized it to "ToIP Services") as it does for them to offer VoIP services. (Now you can see why @jljordan42 coined the term "ToIP".)

[sawhitmire]

I am Scott Whitmire and I retired about six months ago after having worked for a healthcare startup for a year. Before that, I worked as the chief technologist for a brain cancer research lab at the Mayo Clinic in Arizona. I got involved in the ToIP Foundation shortly after it formed in 2020 as part of my work as vice chair of a IEEE Standards working group. The ideas of ToIP combined with those of health record banks fit nicely with what we were trying to do with the standard. The concept of the hourglass for the TSP is spot on, but it may be a completely different animal that the IP layer, since the TSP runs on top of either TCP or UDP and thus relies on the IP layer. So what needs to go into the TSP? So far, it's a very good question.

[talltree]

Scott, I think it was your question about how the Hourglass Model applied to the TSP that prompted @SmithSamuelM to create the presentation he gave last Wednesday to the APAC meeting of the Trust Registry TF. As you can see, I'm cross-posting all over the place today asking TSPTF members to watch that presentation — both to answer your question about the Hourglass Model and to set up Sam's talk on his TSP proposal in the TSPTF meetings this coming Wednesday (Feb 8).

[sawhitmire]

I just watched Sam's presentation and it does clarify things quite a lot. Routing and discovery don't need to be part of our problem because we can rely on what the IP stack already provides. We just need to be able to address the security, trust, and reputational questions that come up in our work. I suspect a trust chain of verifications (verify the provenance of the message, then the sender, then the sender's identity...until I can make a trust decision). This does change the discussion quite a lot, but also reinforces my suspicion that the TSP is really common issue and verify operations that don't make any decisions, but do the basic stuff that everyone will need to do to create an ID or verify a claim (one link in the chain).

[pancaldi]

Hi all,
Greetings! This is Jacques Bikoundou, and I have been a ToIP member since 2020. I am blockchain certified in Hyperledger Aries development and blockchain strategy (INSEAD). Up to this point, I have been mostly contributing to ToIP governance framework projects such as CCI, SSI Principles, GHPC, and the recent SSI Harms. I am currently a WG member of the Technology TF (AIM). Happy to continue contributing to the TSTF.

[IDmachines]

Hi, Sal D'Agostino, at IDmachines we provide stanadards based technology and services since 2008, before that in 2003 CoreStreet developing and deploying validation services for digital certificates, and identity and physical access control, and before that 18 years at Computer Recognition Systems, a computer vision company providing industrial e.g. note inspection and security, e.g. license plate reading (1st commercial application, tunnel in London..), IDmachines also runs a test lab for the "card reader" to "door controller" ISO/IEC (60839-11-5) verification for the US Security Industry Association (also the SDO). At ToIP initially notice and consent and a controller credential, now looking to align that with governance and registry efforts and ongoing work in Kantara Initiative and W3C Consent Community, in terms of TSP mostly interested in the T, and like with x.509 above what might the dial tone be in the TSP case, which I hope I got right given all the telco folks here..