Meeting Date

  • The ToIP Trust Registry Task Force (TRTF) meets weekly twice every Thursday at the following times (to cover global time zones - see the Calendar of ToIP Meetings for full meeting info including Zoom links):
    • NA/EU 07:00-8:00 PT / 15:00-16:00 UTC 
    • APAC 18:00-19:00 PT / 02:00-03:00 UTC

Zoom Meeting Link / Recording

Attendees

NA/EU Meeting

APAC Meeting

Agenda Items and Notes (including all relevant links)

TimeAgenda ItemLeadNotes
5 min
  • Start recording
  • Welcome & antitrust notice
  • Introduction of new members
  • 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:
5 minReview of previous action itemsChairs
30 minsFinalization of the objective statementChairs

Antti Kettunen proposed small reviews to the objective statement drafted in last week's meeting, see Github Discussion

Drummond Reed walks through his proposal on a wordsmithed version of the objective statement.

Discussion & consolidation

15 minsDeliverablesChairs

Defining the scope of deliverables based on the objectives.

  • Trust Registry Trust task specification
  • Contextual Trust Decision Protocol (Trust Task)


15 mins(APAC) Overlaying the Trust Registry Considerations onto the ToIP Stack

Jo Spencer

https://github.com/trustoverip/tswg-trust-registry-tf/discussions/91
5 mins
  • Review decisions/action items
  • Planning for next meeting 
Chairs

Antti Kettunen add Zoom recordings to TRTF wiki.

Screenshots/Diagrams (numbered for reference in notes above)

#1

APAC:

Alex :

  • Way of identifying and fetching trust registries and trust registry entries using did urls. 
  • Similar to service discovery. 
  • Addressable Resources. 
  • TRP might use did linked resources for identification. 
  • Presentation: 30 min required
  • Requirement Translation:
    • TR to have a persistent and unique identifiable. 
    • TR SHOULD have historical versioning and be retrievable. 
  • Drummond:

Drummond: 

  • You know, it could be really cool for this TF to publish guidance on best practices for implementing a TR on:
    • a) DNS (Jacques’ proposal)
    • b) blockchain (Alex’s proposal)

Chat File:

19:36:30 From Neil Thomson to Everyone:
    Like to point to Jo Spencer's posting in Slack as worth reading...
19:36:51 From sankarshan mukhopadhyay to Everyone:
    Replying to "Like to point to Jo ..."
    
    https://github.com/trustoverip/tswg-trust-registry-tf/discussions/91 ?
19:37:38 From Andor Kesselman to Everyone:
    Replying to "Like to point to Jo ..."
    
    correct
19:41:50 From Andor Kesselman to Everyone:
    Discussion here btw: https://github.com/trustoverip/tswg-trust-registry-tf/discussions/85?sort=new#discussioncomment-5399965
19:43:25 From Sam Curren to Everyone:
    Governance based only on a trust registry is implicit governance.
19:43:53 From Sam Curren to Everyone:
    Regulation CAN be the governance.
19:44:19 From Andor Kesselman to Everyone:
    Reacted to "Regulation CAN be th..." with 👍
19:45:34 From Neil Thomson to Everyone:
    There is clearly a chain of governance, which (as we know) is dictated by (legal) jurisdiction) - will propose that chain (diagram needed)
19:46:25 From sankarshan mukhopadhyay to Everyone:
    What might be a legitimate example of “you do not have governance” in the context of Drummond’s point that there’s likely governance in the informal “tribal” knowledge as well.
19:47:10 From Drummond Reed to Everyone:
    Reacted to "Regulation CAN be th..." with 👍
19:48:12 From Darrell O'Donnell to Everyone:
    “pretty close” (per Tim) - are we close enough to move on?
19:49:01 From Drummond Reed to Everyone:
    Reacted to "“pretty close” (per ..." with 👍
19:49:38 From Sam Curren to Everyone:
    We can easily allow 'default' governance that states that the registry IS the authority, and those that control the registry make the decisions.
19:49:50 From Drummond Reed to Everyone:
    Reacted to "We can easily allow ..." with 👍
19:50:13 From sankarshan mukhopadhyay to Everyone:
    Reacted to "We can easily allow ..." with 👍🏽
19:51:31 From Andor Kesselman to Sam Curren(Direct Message):
    on fire today. nice comments.
19:51:49 From Andor Kesselman to Everyone:
    Reacted to "We can easily allow ..." with 👍
19:52:03 From Drummond Reed to Everyone:
    Michael’s point is that governance can be federated, so it is a whole series of governance frameworks.
19:52:32 From Viky Manaila to Everyone:
    Reacted to "Michael’s point is t..." with 👍
19:52:43 From Sam Curren to Andor Kesselman(Direct Message):
    Thanks. Realized yesterday that I speak too much on some topics, not enough on others. Comments in chat is a way for me to speak more boldly, without spending mic time.
19:52:57 From Andor Kesselman to Sam Curren(Direct Message):
    yea…good call. good points.
19:55:39 From Dan Bachenheimer to Everyone:
    Replying to "Michael’s point is t..."
    
    but the federation needs governance as well... right
19:56:13 From Darrell O'Donnell to Everyone:
    I move to accept the Drummond version
19:56:21 From sankarshan mukhopadhyay to Everyone:
    Reacted to "I move to accept the..." with 👍🏽
19:56:31 From Neil Thomson to Everyone:
    Reacted to "I move to accept the..." with 👍🏽
19:56:34 From Sam Curren to Everyone:
    Reacted to "I move to accept the..." with 👍🏽
19:56:58 From Scott Perry to Everyone:
    +1 Savita.  Therefore the establishment of a Trust Registry adds the minimum level of governance to a community.  In the Governance Stack Working Group we can add governance specifications above that minimum
19:57:11 From Dan Bachenheimer to Everyone:
    Reacted to "I move to accept the..." with 👍🏽
19:57:42 From Darrell O'Donnell to Everyone:
    either are sufficient to move forward with - we can adjust later
19:57:49 From Drummond Reed to Everyone:
    Reacted to "either are sufficien..." with 👍
19:57:59 From Drummond Reed to Everyone:
    Reacted to "I move to accept the..." with 👍🏽
19:58:01 From Tim Bouma to Everyone:
    I am fine either way. I think we have enough clarity to move forward.
19:58:09 From Drummond Reed to Everyone:
    Reacted to "I am fine either way..." with 👍
19:58:25 From Savita Farooqui to Everyone:
    Reacted to "I move to accept the…" with 👍
19:58:52 From Dan Bachenheimer to Everyone:
    Mr. DNS - does Internet Protocol work without DNS? yes... perhaps not so well - but not required
19:59:32 From Jacques Latour to Everyone:
    just joined
20:00:39 From Darrell O'Donnell to Everyone:
    HL-Indy did! (i.e. didn’t use DNS)
20:01:32 From Antti Kettunen to Everyone:
    https://github.com/trustoverip/tswg-trust-registry-tf/discussions/61
20:02:07 From Michael Palage to Everyone:
    Replying to "Mr. DNS - does Inter..."
    
    Yes - Vint and Bob's work on TCP/IP was operational and deployed long before Paul  and Jon conceived of the DNS in the 80s.
20:03:08 From Mathieu Glaude to Everyone:
    Although an Indy DID can’t be considered as authoritative
20:04:02 From Jacques Latour to Everyone:
    Replying to "Mr. DNS - does Inter..."
    
    if we don't use DNS, then you need a single /etc/hosts file with everything in it, that's going back to 1980... ;)
20:06:19 From Sam Curren to Everyone:
    Agree - it should be all about the protocol.
20:06:26 From Drummond Reed to Everyone:
    Reacted to "Agree - it should be..." with 👍
20:06:45 From Savita Farooqui to Everyone:
    Basically we define the interface, not how it is implemented
20:07:02 From Darrell O'Donnell to Everyone:
    Replying to "Although an Indy DID..."
    
    at that point in time there was no DID!
20:07:51 From Sam Curren to Everyone:
    Reacted to "Basically we define ..." with 👍
20:07:57 From Scott Perry to Everyone:
    I suggest we rename the Trust Registry Specification to Trust Registry Technical Specification which includes minimum governance.  This opens the door for a Trust Registry Governance Specification to be built to complement when that is warranted.
20:08:31 From Neil Thomson to Everyone:
    Protcols?          As suggested in another thread - there are 2 protocols: "consumer" (can I trust this Issuer) and "administrator" protocols (CRUD on TR entries)
20:09:29 From Sam Curren to Everyone:
    Replying to "Protcols?
    
    As sugges..."
    
    I think we should focus on the 'consumer' protocol. management protocols could be a reach goal, but also must remain optional. The only thing that MUST be fixed is the consumer side.
20:09:57 From Neil Thomson to Everyone:
    Replying to "Protcols?          As sugges..."
    
    +1 on pushing admin to the project "parking lot"
20:10:40 From Jacques Latour to Everyone:
    ok, the trust registry API is reachable via a URI URL, like, https://trustregistry.ca/api/readsomething, so there's a domain name for the trust registry, the domain name is in the DNS, and that's part of the internet innerworkings.  otherwise it would be https://213.12.54.23/api/readsomething ...
20:11:58 From Darrell O'Donnell to Everyone:
    “Trust Tasks” as carried out “using a trust task protocol” is a goal. We don’t have any operating trust tasks in the wild.
    
    The key here is that we need to get to concrete implementations of our specification.
    
    The first and simplest will, IMO, be a RESTful API. That will support the Trust Registry Protocol Specification v2. Other implementations will exist.
20:12:35 From Drummond Reed to Everyone:
    Reacted to "“Trust Tasks” as car..." with 👍
20:12:54 From Sam Curren to Everyone:
    Reacted to "“Trust Tasks” as car..." with 👍
20:13:37 From Savita Farooqui to Everyone:
    Reacted to "“Trust Tasks” as car…" with 👍
20:14:05 From Darrell O'Donnell to Everyone:
    There is a tension between the abstract (Actors or Roles) and simple (Issuer, Verifier, …). Great APIs that achieve large scale adoption are simple. The reason, in my view, is that developers are lazy and just want answers. Causing them to understand new mental frameworks leads to low adoption.
20:14:07 From Sam Curren to Everyone:
    Replying to "ok, the trust regist..."
    
    You don't necessarily need to 'trust' the DNS however, it can be a simple facilitation mechanism. I think DNS being used or not is fairly uninteresting.
20:14:33 From Drummond Reed to Everyone:
    Replying to "Protcols?
    
    As sugges..."
    
    I also agree that an admin protocol is out of scope for V2. Possibly in scope for a future version (I would consider the admin operations to be a different trust task.)
20:14:45 From Sam Curren to Everyone:
    Reacted to "I also agree that an..." with 👍
20:14:54 From Drummond Reed to Everyone:
    Reacted to "There is a tension b..." with 👍
20:14:57 From Mathieu Glaude to Everyone:
    Protocol is an orchestration between “consumer” and “trust registry”. Once that’s done we can define the API based on trust task needs. Something like this is what should be expected in the protocol definition: https://github.com/hyperledger/aries-rfcs/blob/main/features/0037-present-proof/credential-presentation.png
20:15:07 From Viky Manaila to Everyone:
    https://ec.europa.eu/digital-building-blocks/wikis/display/TLSO/TL+manager+v5.6
20:15:29 From Viky Manaila to Everyone:
    here you have the EU TL manager with specs
20:15:29 From Jacques Latour to Everyone:
    check this presentation from last week, on how DNS and DNSSEC (crypto signatures enabled authenticity of DNS)           https://icann76.sched.com/event/1J2JA/dnssec-and-security-workshop-1-of-3     DID to DNS : https://static.sched.com/hosted_files/icann76/98/2.2%20CIRA%20-%20ICANN76%20DNSSEC%20Workshop%20-%20DID%20to%20DNS%20v2.pdf
20:15:33 From Sam Curren to Everyone:
    Replying to "Protocol is an orche..."
    
    Way simpler, I think.
20:15:34 From Darrell O'Donnell to Everyone:
    TCP/IP was a “I can transmit stuff” layer.
    SMTP/POP allowed for “I can do email”.
20:15:43 From Darrell O'Donnell to Everyone:
    Reacted to "check this presentat..." with 🎉
20:16:08 From Darrell O'Donnell to Everyone:
    Email builders didn’t use TCP/IP - not once they didn’t have to at least.
20:16:33 From Sam Curren to Everyone:
    Replying to "Email builders didn’..."
    
    Didn't 'directly' use TCP/IP. They work at a higher layer.
20:16:34 From Tim Bouma to Everyone:
    add 👍
20:16:44 From Drummond Reed to Everyone:
    Replying to "Email builders didn’..."
    
    Exactly. Developers who use the Trust Registry Protocol won’t have to know anything about the Trust Spanning Protocol.
20:17:07 From Andor Kesselman to Antti Kettunen(Direct Message):
    We keep going into solutions, without talking about what the requirements are. We need to stick to, what requirements the solution needs to cover, then go into possible implementations.
20:17:25 From Christian Heimann to Everyone:
    Hat auf "There is a tension..." mit 👍 reagiert
20:17:33 From Neil Thomson to Everyone:
    Reacted to "check this presentat..." with 🎉
20:17:35 From Christian Heimann to Everyone:
    Hat auf "“Trust Tasks” as..." mit 👍 reagiert
20:17:40 From Sam Curren to Everyone:
    Replying to "Email builders didn’..."
    
    I don't think that's quite right Drummond. Users of Trust Task Protocols think at the Trust Task Layer - Trust Registry Protcols are at that layer.
20:18:02 From Mathieu Glaude to Everyone:
    +1
20:19:07 From Drummond Reed to Everyone:
    Replying to "Email builders didn’..."
    
    That’s what I meant, Sam. Sorry if I wasn’t clear.
20:19:25 From Sam Curren to Everyone:
    Reacted to "+1" with ➕
20:19:25 From Neil Thomson to Everyone:
    Interesting diagram from @Jacques L. Does a TR replace the Verifiable Data Registry (which must include the core VDR data)?
20:20:16 From Sam Curren to Everyone:
    APIs are not a bad answer, but depends on how well we want to fit on top of the Trust Spanning Protocol.
20:20:24 From Darrell O'Donnell to Everyone:
    Specification and Implementation are clearer terms. “protocol” is incredibly loaded.
20:20:31 From Jacques Latour to Everyone:
    both, look at the preso, the DID is resolved in the VDR, and authenticated further in trust registry
20:21:01 From Drummond Reed to Everyone:
    A protocol is implemented via an API.
20:21:06 From Sam Curren to Everyone:
    Reacted to "A protocol is implem..." with ➕
20:21:14 From Mathieu Glaude to Everyone:
    Interesting diagram from @Jacques L. Does a TR replace the Verifiable Data Registry (which must include the core VDR data)?
    You need somewhere to discover/resolve a DID. And you need somewhere to verify authoritativeness.
20:21:56 From Christian Heimann to Everyone:
    Hat auf "Specification and ..." mit 👍 reagiert
20:21:58 From Mathieu Glaude to Everyone:
    Reacted to "A protocol is implem..." with ➕
20:22:18 From Jacques Latour to Everyone:
    Reacted to "A protocol is implem..." with ➕
20:22:30 From Drummond Reed to Everyone:
    Replying to "Interesting diagram ..."
    
    DID resolution is its own protocol.
20:22:39 From Mathieu Glaude to Everyone:
    @Sam why do you say “simpler”?
20:22:57 From Jesse Carter to Everyone:
    Reacted to "A protocol is implem..." with ➕
20:22:59 From Mathieu Glaude to Everyone:
    Replying to "Interesting diagram ..."
    
    Yes
20:23:09 From Sam Curren to Everyone:
    The real question: Do we require the orchestration to happen on top of the Trust Spanning Protocol?
20:23:24 From Antti Kettunen to Everyone:
    Reacted to "The real question: D..." with 👍
20:23:50 From Sam Curren to Everyone:
    Replying to "@Sam why do you say ..."
    
    Because the 'consumer' interaction with a Trust Registry is much simpler than credential exchange.          That protocol is much more complex than our needs.
20:24:24 From Drummond Reed to Everyone:
    DNS is a protocol. SMTP is a protocol. We need to define a protocol.
20:24:39 From Jacques Latour to Everyone:
    if it's a protocol, then it's something that runs on top of port 97 (example) on top of TCP, UDP or QUIC, and it's socket based protocol...
20:24:44 From Andor Kesselman to Everyone:
    Replying to "The real question: D..."
    
    Great question. Needs to be part of the requirements collection. I’m not sure tbh.
20:24:49 From Mathieu Glaude to Everyone:
    +1 Drummond
20:25:13 From Viky Manaila to Everyone:
    Reacted to "DNS is a protocol. S..." with 👍
20:25:47 From Jacques Latour to Everyone:
    Reacted to "DNS is a protocol. S..." with 👍
20:25:57 From Steve McCown to Everyone:
    Reacted to "DNS is a protocol. S..." with 👍
20:26:16 From Darrell O'Donnell to Everyone:
    Replying to "The real question: D..."
    
    No. If we require TSP we have self-limited who/what can access the system. For real-world things - we have zero places to integrate. Our job, IMO, should be opposite. Hundreds or thousands (or more) registries already exist. Getting at them is utterly inconsistent.
20:26:33 From Jacques Latour to Everyone:
    SMTP protocol (port 25) does name resolution via DNS (port 53)….
20:27:40 From Sam Curren to Everyone:
    Replying to "The real question: D..."
    
    Do we require one on the TSP, one via HTTP API?
20:27:52 From Andor Kesselman to Everyone:
    Replying to "The real question: D..."
    
    I’ve heard some people wanting to constrain the TSP work to ToIP stack. I think we need to put some thought into this. There’s a reason the TSP will provide additional support that may be really important.
20:28:06 From Mathieu Glaude to Everyone:
    All trust tasks are defined as protocols, and implemented using various solutions.
20:28:20 From Jacques Latour to Everyone:
    Reacted to "All trust tasks are ..." with 👍
20:28:30 From Drummond Reed to Everyone:
    Replying to "All trust tasks are ..."
    
    Exactly right, Mathieu.
20:28:54 From Sam Curren to Everyone:
    Reacted to "All trust tasks are ..." with 👍
20:29:06 From Viky Manaila to Everyone:
    Reacted to "All trust tasks are ..." with 👍
20:29:22 From Neil Thomson to Everyone:
    All trust tasks?           Is there a list of all the trust tasks (e.g., DIDComm list as presented in Dan Hardman's #2 TSL proposal?
20:29:32 From Darrell O'Donnell to Everyone:
    Replying to "The real question: D..."
    
    @Andor - constraining TSP on ToIP stack makes sense to me. It is defiining something new. A new way to establish trust. It’s the opposite of the trust registry realm.
20:30:12 From Andor Kesselman to Everyone:
    https://github.com/trustoverip/tswg-trust-registry-tf/pull/90 PR

Decisions

  • Sample Decision Item

Action Items

  • Sample Action Item


  • No labels