Meeting Date

• May 2, 2025 This meeting was set up in response to interest and activity on Trust Registries in the APAC region.

Zoom Meeting Link / Recording

Video Conferencing, Web Conferencing, Webinars, Screen Sharing

• @Alex Tweeddale

• @Antti Kettunen

• @Darrell O'Donnell

• @Fabrice Rochette

• @Daniel Bachenheimer

• @Keren Leung

• @Scott Perry

• @Eric Drury

• @Shafayet Ahmed

• @Jon Bauer

Agenda Items and Notes (including all relevant links)

Agenda Agenda Items :

• [ Andor ] Baseline core doesn't make vocabulary positions.

• [ Darrell ]

  • Andres used the word opaque string?

  • What do I put in there?

• ABNF approach

• Spec side :

  • Progress on the protocol

  • Separate the spec with the vocabulary

[Drummond]

• spec that says you have two endpoints that can talk to each-other.

• overall structure of a query.

• how useful is there without a query language

[ Fabrice ]

• agree, that’s why I like the Authority Statement approach that makes the spec simple

[ Darrell ]

• if you need to know the intricacy of the system of record to ask the question, this becomes a challenge.

[Darrell]
If I receive a governance framework that says "bc_corporation_signing" and "bc_sole_proprietor_signing" are the two kinds of queries that they support that’s great. They are sophisticated implementers and may not want a vocabulary forced upon them.

Other systems-of-record may want guidance - great, here is a way to do this - that drives toward convergence (and inferred interop)

[Drummond]
I think the best thing about the Authority Statement model is that it simplifies the design of the query language (I started out just called it vocabulary, but from all the issues, I think it’s more accurate now to just call it a simple query language.)

[Drummond]
Authority statement model simplify the space .
Two approaches:

• Every ecosystem describes what they want

• DNS based approach, with clearer semantics.

[ Fabrice ]
it’s like the TXT used in DNS

[ Alex ]
Trust Registry Query Language (TRQL) 👀

[ Andor ]
I really like TRQL

[ Alex ]
Also is a complimentary spec to the emerging Digital Credential Query Language

[ Andor ]
Yep. I was thinking about it. It’s basically a DCQL for TRs.

[ Andor ]
Also the API spec seems to be moving around .

[ Drummond ]

• Good reason to separate core from bindings.

• Counter point : Bindings can be in the spec and we can version.

• TSP Binding : Discussed with Wenjing. Need the query language.

[ Antti ]

• TRQL : Defining a semantic modeling.

• Second: Abstractions: If we only have initially one spec. Keep it in this spec.

• Keep it in the same spec.

[ Darrell ]

• DNS - where did the various strict types come from?

• They came from TXT - informal use of things that ended up becoming the formal things (MX, A, CNAME,…).

• Interestingly SPF became a formal record type, but was deprecated back to TXT. Likely due to major camps using them (and formatting them) in wildly different ways

• APAC Call :

  • Bi-weekly. Next call is next week.

  • Affinidi might want to join.

  • Singapore :

    • Challenging timezone.

    • EU/APAC call : someone else would need to be a co-chair

    • Looking for a lead.

  • No Vocabulary in assertion Query

Antti :

• Separation.

• Should remain closely bound to the development of the TRQP.

• People will be the same.

Fabrice:

• @Drummond Reed (Gen Digital) agree, at least TRQP will stabilize faster if we separate

Lets have a clear note to explain the distinction between TRQP and TRQL so that those outside this call aren't confused

TRQL is a MUST, not a SHOULD

[ Alex ]

I think it makes sense to have a separate repo

[ Fabrice ] : agree

[ Darrell ] : agree

[ Drummond ] : agree

[ Fabrice ] : it’s better for the ecosystem if they see that TRQP is stabilizing and we provide a stable release.

[Fabrice ] : that’s better for generating community interest and implementors

[ Darrell ] : Needs to be clear what we are working .

[ Drummond ] : One more benefit of the TRQL name is that it suggests the very close binding to the TRQP core spec.

[ Antti ] : More practical approach of how to make this happen. Challenges/Dangers from an adoption.

DECISION:

• Consensus :

  • TRQL spec to be created.

  • Separation : In the TRQP spec, there is a query language and this is a separate deliverable. And go here to contribute to it.

• Action Items:

  • Rename the current wiki page

• [ Antti ] : So… we’re not far from Trust Registry Suite (TRS)? 🙂

• [ Alex ] I think it should all be under the same Task Force (TRTF), to avoid fragmentation - as Antii mentioned

• [ Alex ] TRQL really starting to come out of its shell!

Notes: