Time

Agenda Item

Lead

Notes

3 min

• Start recording

• Welcome & antitrust notice

• New member introductions

• Agenda review

Chairs

• 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:

2 min

Review of previous action items

Chairs

None

5 mins

New Rotating Meeting Schedule

@Drummond Reed

Due to the Daylight Savings time shift, it is proposed that we have rotating calls.

1. First rotation sticks with our current time slot: 06:00 PT / 09:00 ET / 14:00 UTC / 15:00 CET / 01:00 AEDT

2. Second rotation will be: 14:00 PT / 17:00 ET / 22:00 UTC / 23:00 CET / 09:00 AEDT

We will take next week off for U.S. Thanksgiving, then begin the second rotation the following week.

ACTION: @Drummond Reed to notify @Michelle Janata about moving to the new meeting rotation starting with the second rotation for the Dec 5th meeting. First rotation: 06:00 PT / 09:00 ET / 14:00 UTC / 15:00 CET / 01:00 AEDT; Second rotation: 14:00 PT / 17:00 ET / 22:00 UTC / 23:00 CET / 09:00 AEDT.

15 mins

X.509 bridge discussion

@Scott Perry

Scott posted the following to Slack:
In thinking through how to make x.509 certificates interoperable with the rest of the protocols mentioned above, the focus should be on two core PKIX constructs: 1) Certificate profile extensions and 2) Object Identifiers.  I have found a pretty good education site that I suggest people visit so that they can be more conversant: Education Center | Explore Now | Encryption Consulting
What Is Object Identifier In PKI? | How To Obtain An OID ..  To achieve our objectives, I'm leaning towards creating a new RFC based on our own specification work, similar to this one: RFC 6487: A Profile for X.509 PKIX Resource Certificates . I personally do not have the technical depth to complete this.  I am seeking (and request all of you) to recruit someone who can.

@Scott Perry These are the “dials and knobs” for communicating a standard structure in X.509. GLEIF did that in the ISO standard. Scott and Drummond will get a copy of the standard to see how it is structured there. Then we need to do the same analysis for our spec. Then we need to determine the OID. We can also create an IETF RFC specific to our profile if we want that leg of the bridges to be easily accessible.

Scott is recruiting an X.509 PKI expert to assist with that work. Ideally that person could join us.

Scott also pointed out that different OIDs can be used for different assurance levels. They can depend on how the private key is stored and the strength of the hardware.

ACTION: @Scott Perry and @Drummond Reed to get a copy of the ISO spec for LEIs in X.509 certificates.

30 mins

Structure of the HAVTF specification (and preparation for writing assignments)

Chairs

Given our consensus that the spec should focus primarily on the technical requirements for each type of bridge, we should discuss how best to structure the overall spec. That will then lead to writing assignments.

@Tim Bouma shared screenshots #1 - 3 below that he and @Jesse Carter created for last week’s meeting. They illustrate the different elements we need to bring together in the spec, including the bidirectional bindings.

It does not necessarily deal with discovery except with those technical standard sets that include discovery, like DNS.

@Jesse Carter said that the underlying pattern that is emerging is bidirectional pointers (sort of like 2FA). If both sides agree, that creates the high-assurance bridge.

So if each of the bridge methods specifies how to build the bidirectional bridge between any two identifiers. It is a “two-lane bridge”.

We discussed that there will only be so many sites/orgs that will be able to easily implement these bridges until their tooling supports them.

Tim made the point that the higher assurance of the bridges is different than the higher assurance of an X.509 and should not be confused.

Scott said that the CAs must do some type of vetting of a website. LetsEncrypt is one example of a CA that we could look into to understand how they do their due diligence.

Tim explained that LetsEncrypt has a utility that the website owner installs in order to prove control over the website. It is basically two processes/agents talking to each other. Since it is all automated, there’s no cost associated.

The same process is specified in the GLEIF vLEI Ecosystem Governance Framework by using a KERI-based process.

Tim felt that we should point to such procedures but we don’t have to specify them.

Tim explained how it works at Bluesky. They use a third-level DNS domain to point to a DID. Tim found a site on GitHub that resolves the Bluesky DNS name to a DID so you can inspect the DID document.

Tim said that Bluesky does not want to be responsible for “KYC” for a Bluesky handle; Bluesky only provides the mapping.

@sankarshan: ““Not being on the hook for KYC” would be an interesting conundrum when Bluesky hits the .au requirement for age based restrictions around access to social networks. But this is not necessarily new though - Yoti and others have been doing this for a while.”

ACTION: @Tim Bouma and @Jesse Carter will propose how to “fill the pigeonholes” for the TODOs in the table in screenshot #3.

CA Browser Forum

@Scott Perry

Scott shared that the CA Browser Forum gets involved with setting standards for when a browser invokes the browser root store. Other PKIs that do not use the browser root store do not involved the CA Browser Forum. So it is not a requirement to interact with the CA Browser Forum (which can be challenging and take a long time).

5 mins

• Review decisions/action items

• Planning for next meeting 

Chairs