Drummond Reed 

Drummond will report reported on the new direction for the X5VTF and how it should produce . Rather than trying to turn an X.509 certificate into a DID, the specification will focus on standardizing how to add a DID to an X.509 cert. This should result in one clear option for bridging between VIDs and X.509 certificates.

Markus Sabadello ______ said it is also important to look at how to go in the other direction, i.e., from a DID to an X.509 cert, including the option of embedding the cert in a DID document.

ACTION: Drummond Reed to connect with Markus Sabadello offline to discuss collaboration how the X.509 VID TF could collaborate with the DIF ID WG and the W3C DID WG.

Kyle Robinson asked about how this would involve CAs and how it is involved with trust registries.

Jacques Latour answered the question: "CA: Trust the CA to issue the cert as per define BCP. Trust Registry: use the CERT as per governance."

Wenjing reported that the project is making good progress, and that a V1 of the project should be ready sometime in August. All the major features are supported. It includes a testbed with both a CLI and Web interface that can show message paths and some simple applications.

One example is using a timestamp service offered by an intermediary.

The CLI allows a developer to look into the messages and flows much deeper.

The performance is pretty good so far, but still remains to be seen for embedded devices and other constrained use cases.

The DIDs supported so far are did:peer and did:web. did:tdw is coming. There is discussion of other DIDs.

The transport protocols supported so far are HTTPS / TLS and QUIC. Hopefully those will be sufficient examples.

Language bindings: the core libraries are coded in Rust. There is also a browser integration so you can call the protocol from a Web implementation. On the cloud side, there is already a binding for Python and Node.js. Additional bindings should be relatively straightforward.

The plan is to publish this together with some developer documentation sometime in August.

Drummond suggested that this would be a good time for another progress milestone blog post. Wenjing agreed, and said that it could provide an opportunity to start discussions about next steps with higher level protocols.

Wenjing also said that this milestone would be a good time to address open issues in the spec and produce a second Implementers Draft. We could shoot for the October IIW. 

Judith Fleenor asked about the status of the CESR implementation in the OWF TSP project, noting that the ACDC TF observed that the OWF CESR implementation was not full CESR support. Wenjing explained that for TSP, CESR is used for message framing, and is optional for other body content. There is already a RUST implementation of full CESR, so that can be used. Wenjing's team decided to implement just the minimum version of CESR for the basic message framing, but using a full CESR library should be straightforward.

Charles Lanahan explained that the CESR implementation in the Web of Trust project implements CESR 1.0 and has been "kind of dormant", but is in production use.  Drummond asked if there was a plan to upgrade it up to CESR 2.0. However there are some obstacles to doing this; the community is working on it.

Wenjing expressed that it would ideal to have a common path forward with a full CESR 2.0 Rust library.

Judith suggested two blogs: one in August about the OWF TSP milestone, and one right before IIW about a second Implementers Draft.

Drummond Reed and Wenjing Chu to coordinate with Judith Fleenor on scheduling two blog progress milestone blog posts: one in August about the OWF TSP milestone, and one right before IIW about a second Implementers Draft.

All

Use of the "raw" TSP is likely to be as rare as use of "raw" IP. This will be an open discussion of which trust task protocols are the "lowest hanging fruit".

Wenjing said that a simple trust task protocol can be a one-day project. 

One of the simplest examples that his team tackled was to add a verifiable timestamp to messages. This timestamp service can be provided by a TSP intermediary. It can be done in the non-encrypted portion of the message or inside the encrypted portion. This is a very simple example of a trust task protocol.

An obvious next step is verifiable credential issuance and exchange protocols, such as those already implemented in DIDComm V1 and V2.1.

Another example Wenjing brought up is content authenticity. This was the subject of his presentation to the ToIP All-Members Meeting.

Jacques Latour: is this a use case?  Browser to query trust list c2pa-explorations/trust-lists/trust-lists.md at main · christianpaquin/c2pa-explorations (github.com). Jacques explained that Christian was building a browser plug-in to look up a C2PA claim signature in a trust list.

Neil Thomson mentioned the trust task of doing the dynamic VID appraisal that Samuel Smith explained in detail in our last meeting.

Charles Lanahan asked why any of these trust tasks are specifically appropriate for TSP. Wenjing answered that the TSP provides the baseline spanning protocol over whichever trust task protocols can be performed. Doing layering in this way makes the trust task simpler to implement and also enables interoperability for that particular trust task.

Wenjing emphasized that a particular blockchain represents a trust domain, and with the TSP, our goal was to enable crossing any trust domain that is VID-compatible.

Drummond Reed to put a continuation of this discussion on the agenda for the next TSPTF meeting on August 7.