Define TRTF Deliverables for V2

[andorsk]

For the trust registry task force deliverable, we should define the initial deliverables:

https://docs.google.com/document/d/1T2NIv4wCxqtTkzk76XtcZKP8gFM97u3YYuAscP8ZGX4/edit?usp=sharing

Based on conversations proposed at the TRTF, I'll lead with the following proposal of deliverables:

• Specifications : normative descriptions around trust service support. For more information, see the following issue: Define Scope of TRTF #50
• Companion Guide : non-normative suggestions around best practices and implementation guides.

To Close Issue:

• PR with placeholders for the deliverables.

I will spin up a separate issue related to the audience of the v2 deliverable.

[jacqueslatour]

@jacques - The spec should address global interoperability and unique identifiers and and I see trust registries as the enabler to enable scaling.

Scope to consider: global interoperability and unique identifiers, and how the DNS can be leveraged to enable this.

Also looking at documenting this as an IETF Internet Draft as well, so it can become an IETF standard one day, or BCP.

[andorsk]

Call on Jan 12 at ToIP

@tim Bouma: Agrees with the approach.
@a-fox : Not sure of the deliverables. Any trust decision has a liability into it. Needs to have legal and privacy people involved. Need to think more holistically. Need coherence and positioning so we can scope it better.
Tim: Always going to be debating content. Whatever we arrive at as a group needs to be concise and clear. Any additional context is in deliverable 2. People that care about this deliverable will care b/c lots of leaders are working on the deliverable.
@talltree : w3c also does the same spec and companion guide. Decide the pallet you're painting on. At the proper time, flush it out.
@darrellodonnell : two factors: the world is starting to learn layers 3 and 4. Urgency is required. Questions from the space is there now.
@andorsk liked the canvas concept.
@a-fox : major projects in the EU to be considered.
neil: let's make a matrix of what's being worked on. @a-fox : can use that to inform the scope.
Tim: careful we don't re-invent the wheel.
@talltree : let's remind ourselves of work done in security. DID trust list is fundamentally different than a DNS list. Targets to aim: Once ARF for European Digital Identity Wallet is published viky offered to present.
@a-fox Map input to trust models
jacques: DNS should align to the STRAWMAN. Complement.

Action Step Here:

• @darrellodonnell to throw down a swagger spec as a STRAWMAN
• consensus to start working toward a STRAWMAN deliverable. ALL deliverables.

[andorsk]

APAC call:

• Jo Spencer Context and technical layer should be addressed. Probably in the specification guide.
• @talltree Mission on charter page need to be cleared up:
  • 5 classes of deliverables. Deliverable on trust models should exist somewhere.
  • Decision of deliverables need to align with mission and scope of TF.

[talltree]

@andorsk et al,

The five types of ToIP deliverables are listed on this page of the ToIP website:

1. Specifications to be implemented in code
2. Glossaries to be incorporated in other documents
3. Recommendations to be followed in practice
4. Guides to be executed in operation
5. White Papers to assist in decision making

I would propose that a minimum this TF should have deliverables of types 1, 2, and 4, namely:

1. A ToIP Trust Registry Protocol Specification
2. An accompanying Companion Guide (aka Implementer's Guide).
3. A white paper that can be read by policymakers and others who want to understand what the ToIP Trust Registry Protocol Specification is all about, how it fits within the ToIP stack, and where it fits relative to other related industry standards and solutions.

I could also see another white paper (or a recommendation) about trust models and the equations that have been discussed.

[andorsk]

Love it. @talltree makes sense to me.

For
1: When you say 1 should be implemented in code, what do you mean?
2. Makes sense to me. Does it make sense to add to the terminology working group.
4. Makes sense.
5. I'd argue that 3 is probably pretty important to do as well, even if it's a "trimmed down version".

For 4, are you saying 4 is a white paper? Or is the white paper only in 5?

[darrellodonnell]

I believe 1 "to be implemented in code" means the specification should be implementable, as opposed to "we're providing code that is the spec"

thoughts?

[andorsk]

+1 to that position. I don't think actual code should be done here. Reference implementations can live somewhere else.

[andorsk]

@darrellodonnell I'm not sure though about the OpenAPI specs. I'd like to discuss with you your thoughts on that more. I understood the need for it in v1, but would like to drill down more about the deliverable for v2 and how the OpenAPI specs related to the goals of the project..

[darrellodonnell]

The one exception to "code" in my mind is Compliance Suites. They need a third-party place and are part of a reference architecture. That said, we (ToIP) haven't done that yet.

[darrellodonnell]

We need a logical model that broadly explains the specification. An OAS/Swagger helps get the concrete thinking down so we can really understand what is going on.

[andorsk]

So to add on here: this is the deliverable I would think propose early on:

• Specification guide: Focuses on defining requirements, models, architecture, and guidelines for a trust registry ( to be clear: not any particular trust registry implementation, but the model around trust registries across the ecosystem. )
• Companion Guide: Focuses on how to actually build a trust registry in practice. Non normative.

DIF:

• Leverages the specification and companion guide to build a specific set of technical specs that comply with ToIP's standard.

Analogy to a current technology:

1. ToIP is in charge of defining a container for data (i.e VC). DIF is in charge of figuring out the technical specifics, i.e JSON-LD or JSON Web Token)

Another example:

• the is defined by ToIP ( the interface that the implementation must conform to ): https://github.com/TBD54566975/ssi-sdk/blob/d48966db0f15c5cb32efcc4233d2eb5368adb1ee/cryptosuite/cryptosuite.go#L55 <- note this is code for reference, but in the actual spec this would not be code.
• this is defined by DIF ( the implementation of the interface ): https://github.com/TBD54566975/ssi-sdk/blob/92be548d54be11b3740b95bb5c568958e5979de0/cryptosuite/jsonwebkey2020.go#L181

[darrellodonnell]

a very API based approach, which isn't necessarily how I think about the deliverable/scope.

This is exactly as I see it. We aren't building the Trust Registry - they exist already or are built for purpose as required. We are telling the owners/builders of the registries how to expose their data to the world.

I think this is where we have different views. I'm looking for the simple thing that players in an ecosystem can use to get the answers they need about "playing" in an ecosystem. They want to integrate not build from scratch. Hence the RESTful API spec.

A registry of Professional Engineers could issue credentials and DIDs for engineers to use in signing digital drawings. They already have the list of licensed engineers (P.Eng. in Canada, PE in US) and the business rules for granting license, updating license, and revoking/retiring license. So they already know all of that. They could issue a simple credential "Darrell is a P.Eng. in Ontario" and manage the signing DIDs (Darrell is Authoritative Issuer for signing engineering docs).

They can bolt on an API easily. Same goes for educational institutions, and many, many more. They already have a "System of Record that contains much of the information we need. They are, in effect, the Trust Registry - but there is no consistent way to expose the data. That's where our API spec comes in.

Does this help?

[andorsk]

What if you want to build a TR that's not a RESTful endpoint?

[talltree]

My view is that an API is good but that assumes a RESTful endpoint. So a protocol is even better. You can always implement a protocol by specifying an API for it, but not the other way around — a protocol specification can allow any number of implementations, and they can all be proven to be interoperable by sending and receiving test messages (even if that test harness can get pretty hairy if the protocol is complex).

[andorsk]

Agreed on this point @talltree . It should be as technology agnostic as possible IMO. I'd love if the specs here were so stable, they get thought of similar to how TCP is used in context today. Old reliable. No matter what happens above the stack, TCP hasn't had any breaking changes since it's acceptance (afaik).

[darrellodonnell]

We need to start with something. This is a start.

On Wed, Jan 18, 2023 at 19:36 Drummond Reed ***@***.***> wrote: My view is that an API is good but that assumes a RESTful endpoint. So a protocol is even better. You can always implement a protocol by specifying an API for it, but not the other way around — a protocol specification can allow any number of implementations, and they can all be proven to be interoperable by sending and receiving test messages (even if that test harness can get pretty hairy if the protocol is complex). — Reply to this email directly, view it on GitHub <#61 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFHWBYM6PS3YGVI5BLR4E3WTCZDRANCNFSM6AAAAAAT6P6BSY> . You are receiving this because you were mentioned.Message ID: <trustoverip/tswg-trust-registry-tf/repo-discussions/61/comments/4723787@ github.com>

-- *Darrell O'Donnell, P.Eng.* ***@***.***

[andorsk]

@darrellodonnell weird. where this message come from from @talltree ?

But overall, yes, I agree with Drummond that we shouldn't confine the specs to a Restful API (officially) and should be transport agnostic. That being said: If it's something that gets us moving forward as a STRAWMAN to start thinking about an abstraction, I'm for it as long as it doesn't force us into a weird position during the first public release.

My personal take, we need to start off with an abstraction even beyond a protocol. It could suggest protocol requirements, with different implementations possible.

Here's my (rough) proposal:

classDiagram

   class TRTFSpecificationGuide {
        Terminology and Glossary
        Abstract Data Models
        Interfaces
        Containers
        Higher Level System Requirements
   }
   
   class Terminology {
        Trust Decision
        Trust Services
        Support
   }

   class TrustRegistryInterfaces {
      << interface >>
   } 
    
   class CompanionGuide
   class TrustRegistryProtocol {
       << abstract >> 
   }
   class DIDComm
   class RESTful
   class DWN
   TRTFSpecificationGuide  "1" .. "n"  TRProtocol
   TRTFSpecificationGuide  "1" .. "1"  CompanionGuide
   TRProtocol <|-- DIDComm
   TRProtocol <|-- RESTful
   TRProtocol <|-- DWN
   TRTFSpecificationGuide "1" .. "1" TrustRegistryInterfaces
   TrustRegistryInterfaces <|-- TrustRegistryProtocol
   CompanionGuide ..TrustRegistryProtocol : suggests uses of protocols
   TRTFSpecificationGuide "1" .. "1" Terminology

Loading

My last thought here is that we have to assume a future where we don't know what the technology landscape will look like. Let's make sure we try to detach the concepts in the specifications here as much as possible from actual technology implementations. Interdependence gets us adoption. Complete dependence gets us in a bind.

[JFleenor]

@andorsk I thought you had edited out the word Guide behind the TRFTSpecification, but it seems to still be there in the diagram above.

[JFleenor]

Nevermind, I see the edited one is in a comment below. First time using discussion, getting used to the tool.

[darrellodonnell]

@talltree is Drummond.

On Wed, Jan 18, 2023 at 20:17 Andor Kesselman ***@***.***> wrote: @darrellodonnell <https://github.com/darrellodonnell> weird. where this message come from from @talltree <https://github.com/talltree> ? But overall, yes, I agree with Drummond that we shouldn't confine the specs to a Restful API (officially) and should be transport agnostic. That being said: If it's something that gets us moving forward as a STRAWMAN to start thinking about an abstraction, I'm for it as long as it doesn't force us into a weird position during the first public release. My personal take, we need to start off with an abstraction even beyond a protocol. Here's my (rough) proposal: classDiagram class TRTFSpecificationGuide { Terminology and Glossary Abstract Data Models Interfaces Containers Higher Level System Requirements } class Terminology { Trust Decision Trust Services Support } class TrustRegistryInterfaces { << interface >> } class CompanionGuide class TrustRegistryProtocol { << abstract >> } class DIDComm class RESTful class DWN TRTFSpecificationGuide "1" .. "n" TRProtocol TRTFSpecificationGuide "1" .. "1" CompanionGuide TRProtocol <|-- DIDComm TRProtocol <|-- RESTful TRProtocol <|-- DWN TRTFSpecificationGuide "1" .. "1" TrustRegistryInterfaces TrustRegistryInterfaces <|-- TrustRegistryProtocol CompanionGuide ..TrustRegistryProtocol : suggests uses of protocols TRTFSpecificationGuide "1" .. "1" Terminology — Reply to this email directly, view it on GitHub <#61 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFHWB5XWW5GIHJ47HAY74LWTC53ZANCNFSM6AAAAAAT6P6BSY> . You are receiving this because you were mentioned.Message ID: <trustoverip/tswg-trust-registry-tf/repo-discussions/61/comments/4723913@ github.com>

-- *Darrell O'Donnell, P.Eng.* ***@***.***

[andorsk]

yea..sorry. was referring to for some reason I didn't see the original response from @talltree 👍 . just saw the response inline our comment. thanks.

[andorsk]

I combined the 5 points from Drummond with mine into a single view:

classDiagram
    class TRTFDeliverables {
        Specifications
        Glossaries
        Recommendations
        Guides
        WhitePaper
    }
    
    class Specification{
       Base Data Models
       Interfaces
       Containers
       Core System Requirements
    }
    class Glossaries {
         Trust Decision
        Trust Services
        Trust Support
    } 
    
    class Recommendations {
        Trust Registry Protocol Best Practices
    }
    class Guides {
        Companion Guide
    }
    class WhitePaper
    
    TRTFDeliverables "1" .. "1" Specification  : critical
    TRTFDeliverables "1" .. "n" Guides  : high
    TRTFDeliverables "1" .. "1" Glossaries  : high
    TRTFDeliverables "1" .. "n" Recommendations  : low
    TRTFDeliverables "1" .. "n" WhitePaper  : low 

Loading

[a-fox]

Yes it is an endpoint, but it has its own locus of control. It's not within the wallet's locus of control, whereas all the other layers in the stack are. Supporting systems like VDR & TR are exactly that: they support use of wallet endpoints. We may have many different types of VDR's and TR's, and they may serve other stacks than the ToIP Tech stack, at the same time. This is why it's important to separate and not tightly couple them into the same stack. It gives us flexibility and measures of interoperability.

L1 is about the storage & transport protocols of that specific endpoint system, like a wallet. A Trust Registry doesn't and shouldn't care about that. They have no linkage to how I will form a connection with my wallet to somebody else. They're just supporters in that interaction.

[a-fox]

Here's my rendition in how to describe your layers.

[vladevs]

@a-fox Thanks a lot for the rendition, brings clarity to our discussion. Looking at this and assuming there is a consensus on the scope of this task force ("deliver the input and tools to support the trust decision, not make the trust decision itself"), can we agree that our focus is the Trust Registry API ("this is how you expose your data") and the Trust Decision Protocol ("this is how you connect to the Trust Registry and consume the data") and not on the layers above (at this point, I'm not sure about the boundaries of the Trust Decision Trust Task)?

[andorsk]

@vladevs agree. How you "expose" your data and how do you "connect" to the trust registry. The "how you expose your data" could be exposing "capabilities" of the service, which could be interesting. @a-fox this graph was sincerely helpful. Thanks for putting it up. We are getting a lot closer. Need to keep chipping away.

[a-fox]

That's a good question @vladevs. This is something we will likely dig deeper in today's Task Force meetings! We will likely need to at least be opinionated on everything here (except the business-boxes). Governance is focused in the Trust Registry Governance and L2 trust spanning layer has its own task force. So, I think we need to discuss and align with both sides.

[andorsk]

Here's another STRAWMAN re: deliverables and how they fit together. Let's discuss all these proposals during the next ToIP call

classDiagram
   class TrustService {
         << interface >> 
   }

   class TrustServiceProtocol {
         << interface >> 
   }

   class RESTfulProtocol  
   TrustServiceProtocol <|-- RESTfulProtocol : defines a specific implementation
   RESTfulProtocol <|-- libraryA  : codes

   class Container {
        << abstract >>
   }
   class App {
   }
   TrustService -- TrustServiceProtocol : uses
   TrustServiceProtocol -- Container : depends on
   TrustService --  Container : prepares
   App -- libraryA : leverages

Loading

[darrellodonnell]

Where are the artifacts driving these diagrams?

[andorsk]

As in where to they live?

Think about it this way ( in go terms with HTTP )
TCP is kinda similar to my core "interface" description. technically it's a protocol, but it's so low level and fundamental, that you can build many protocols on top of it (like HTTP ). There's almost an implicit contract that if you want to do most things on the internet, you need TCP. So I guess interface could be changed to low level protocol, but there might be some nuance I need to think more around this.

http would be an example of the restful protocol: https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
library A would be a particular implementation = https://pkg.go.dev/net/http

[andorsk]

To this audience, sharing a diagram of TCP was a bold move 😆

[andorsk]

Discussed on call

graph TD
   HigherLevelTrustProtocols
   TRP
   TSP
   TRP --> TSP
   HigherLevelTrustProtocols --> TRP
   TSP --> TrustSupport

Loading

• neil : might need a new TF around accreditation
• drummon: Trust Registry protocol to add to TATF
• discussion: mostly consensus alignment on call about this model
• @andorsk How do you talk to a trust registry vs. how to build a trust registry
• @talltree This kinda falls into the scope of Governance Architecture - we're looking at the governance of trust registries
• @andorsk : Parallel TCP -> Protocol . DNS -> OAS Spec
• @neil: A differentiator for Registries (over simplification)
• a Trust Registry is about Entities
• a Data Registry is about non-Entity Data (e.g., Metrics, Measures, Balances)
• If IP = DIDs
  • Then TCP = DID resolution
  • DNS = Registry / Indexing of DIDs and resources
  • Trust Spanning = Complex DID URL dereferencing ? :D
• Might need to develop 2 task forces
• @neil: Jacques work is important to reference. Can be thought of as a data registries
• @dan trust registry is analogous to the IANA (Internet Assigned Numbers Authority) and by five regional Internet registries (RIRs)
• TRCP and TRP

[andorsk]

Conversation on 19th:

@darrellodonnell

• define the word protocol. REST was expedient
• create a more logical model. REST was an anchor.
• v1 wanted to use DIDComm protocol.
• @michael:
• Where do DID registries go? Supports it's possible it can go in layer 1.
  • DIDComm can be a very broad trsut spanning protocol.
• @Antti: Not talking about DIDComm. Needs to be abstracted out.
  • Still figuring out all the dimensions
• @tim: thinks its the appropriate vessels to poor content into.
• The specification must be abstract, while implementations may be very concrete.
• @ darrell:
  The goal that I have with the Swagger is two-fold:
  1. Explore the domain and get our thinking aligned (already making an impact).
  2. End up with an API that a systems integrator can bolt onto their system-of-record or use as the external interface to a new system of record. (NOTE: I’ll be adding System-of-Record as a component Andor).
• https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/
• Suma Nair
  • How does governance agree for interop
  • @darrell: Doesn't need to agree for interop. Use what they are doing, not define what they are doing.
• Pamela : Could be a separate note of how it supports a governance for trust.
• @a-fox : The goal for us is to enable different trust models to interface with other layers of ToIP.
• @darrellodonnell : Memberpass example. Simple but subtly complex.

[trbouma]

I love the parallel to to TCP/IP and DNS

IP - enables nodes(machines) to reach each other
TCP - enables a 'network conversation(sessions) between the machines
DNS - enables a lookup to a machine(or service) via a human-recognizable name

For TrustoverIP, the parallel:

DID - 'decentralized identifiers' enables actors(people) to connect with each other
VEP* - 'verifiable exchange protocol' (I just made that up) enables verifiable exchanges (verifiable credentials and/or verifiable exchange) with each other
TRS* = 'trust registry services' (I made that up too) enables trust decisions based on a third party attestation on a DID.

So at, its core, the TRS provides the appropriate third party attestation on a DID.

For example, I can have my own: did:web:trbouma.i, but for someone to actually 'trust' it to provided a high value service (e.g. government service), my did:web:trbouma needs to be registered and vouched for by a trust authority.

[andorsk]

I've been thinking about this @trbouma , let's discuss over the TRTF meeting this week. I'd like to understand it better.

[a-fox]

very interesting @trbouma. I think this fits nicely with trust task & trust decision concepts. IMO 'trusted_did' sounds like a structure for the trust decision trust task. A trust decision trust task parameters should be defined in the governance framework, initiated by one of the transaction parties, and with some parameters selected by the initiator. Here's a quick image expanding your thoughts, and explaining mine.

[andorsk]

@trbouma :

• Very big concept
• Lots of subnetworks
• Currency to scale to 1
• Concept to enable to a TR or Trust Registry Scaled to 1
• Trust tasks and trust registry behind the scenes
• Internet effectively solved node to node connection
• We are adding on ability for entities to have intentions to be conveyed across the network
• primitive: DID
• Define recursive data structure that's simple
• Super simple structure : A DID that DID has scope associated with it. Signed by another DID which represents the context.
• ex. Government of Canada has a DID.
• oAuth protocol inspiration
• Do I trust the intention of this actor? Is that actor authorized?
• Not a traditional PKI security thing.
  • separate intention from authority
  • context might not be responsible for the DIDs.
• What's the intention of the DID
• What is it trying to do
• What is it authorized to
• Governance body to determine the scoping and how how to interact with the entity
• Nomenclature : Trust Register: scales to 1. Cultural register, Language register, etc.
• Abstract protocol and way to think about it.
• Intent: Don't need to have to worry about trust.

graph TD
     GovCanada[Government of Canada]
     Subnationals[Sub nationals] -->| sends over did | GovCanada
     GovCanada -->|signs authorization within context| Subnationals

Loading

[andorsk]

@trbouma @a-fox relevant comment made here: #68 (reply in thread)

[neiljthomson]

What is intent/intention? Example?
How is it different from a specific request (Initial financial transfer - buy your car)?

[darrellodonnell]

Most (all?) of the queries will be asked in a particular context that is controlled by the Ecosystem Governance Framework. Does adding additional context here help?

[trbouma]

I think so, because the same identifier e.g., did:web:timbouma.io might be trusted in one context and not at all in another context. Think of your email - it is a defacto identifier for many accounts - it is not trusted until you register for the account and supply a password.

In the end, the context_id is like a third party attestation about the identifier - 'in this context, we trust that did:web:trbouma.io is a real person/good issuer, etc.) If the trust registry is only intended to work in one context, then it is implied and not needed. But I think we are aiming for a protocol that can operate across many contexts.

[darrellodonnell]

Agreed - but you are posing the question in the context of an EGF.

[darrellodonnell]

The current (v1) spec support a single trust registry being an anchor for multiple governance frameworks.

[neiljthomson]

While trust registries are not a new thing, it's clear (at least to me) that the concept of a Trust Registry built on Authentic Data and uses Authentic Provenance Chains to link from the published object in a "Data Repository" to both crypto-graphic and governance roots of trust is new.

I'm also not clear on what data is required to be stored (in the TR) or accessible through entities within the TR (API(s)) to be verified on-demand. For example - status (revocation) data

[a-fox]

I think we're beginning to reach our limits with the term "Trust Registry".
IMO what we're actually defining is:

1. a Trust Decision Trust Task, which defines the parameters of the trust decision. Meaning how and where the trust decision will receive the actual decision data, and in what form it's expected (API query, VC, etc).
2. A specification of a protocol or a co-protocol that defines how Trust Spanning layer should make those queries.

By abstracting the decision into trust task (decision parameters) and protocol (query & method), we're able to implement a wide array of different types of trust decisions.

[trbouma]

Agree with @a-fox - I think we are on the right path. I have been thinking a lot about what the core of the protocol might look like, and I have distilled it down to this:

a CONTEXT can be represented by a CONTEXT_DID which is under the control of some entity, such as a GOVERNING BODY, who decides the rules, etc, for that CONTEXT

an authorized ACTOR, who has an ACTOR_DID is authorized(scoped) to do certain things within the CONTEXT, for example to be an ISSUER.

So, it would look something like: {"actor_id: ACTOR_DID, "scope": "issuer"}->Signed_by(CONTEXT_ID)

That's about it. This might be a light description, raising lots of questions, but I am quite happy to discuss. I have been working through various scenarios of overlapping authorities (e.g. at an airport) and it seems to hold up. What is fundamentally different than traditional PKI or CA, is that the 'root of trust' is demoted to a context, which can exist in other contexts (modelled as a DID) and have authorities (scopes) within those different contexts. Further, the DIDs can be issued by anyone and authorized by anyone, giving a greater degree of scalability and flexibility that the traditional PKI/CA models.

More tomorrow....

[talltree]

2. A specification of a protocol or a co-protocol that defines how Trust Spanning layer should make those queries.

@a-fox On this one thing, I don't believe the trust spanning protocol should be involved in performing any "trust tasks" beyond the absolute minimum required to support any trust task. In other words, what architecturally separates the Layer 2 trust spanning protocol from the Layer 3 trust task protocols is that any specific trust task protocol is at Layer 3. Layer 2 handles the generic functions common to to all trust tasks.

IMHO, a trust registry protocol is a textbook example of a trust task protocol.

That's why I love it that we have the Trust Registry Task Force (TATF) and the Trust Spanning Protocol Task Force (TSPTF) running in parallel. Designing these two protocols together is much like designing the TCP and IP protocols together (analogous from the standpoint of layering — and spanning — not their actual functions, since everything in the ToIP stack is operating at much a higher layer than the TCP/IP stack).

[a-fox]

That's true @talltree and thank you for making sure we don't blur the lines between Trust tasks & trust spanning layer. I agree that we need to ensure that trust tasks don't pollute the Trust Spanning layer, which needs to be as minimal as possible.
Trust Decisions may have different trust sources (Trust Registry API like EU Trust Lists, Verifiable Credential, direct authorization challenge via DID, DIF Trust Establishment, etc.), which may utilize different protocols (HTTP, UDP, FTP, BT protocols,etc.). This means that Trust Tasks shouldn't care about the underlying protocols, but rely on the TSL on understanding how to communicate within the given connection.

Questions to @talltree & @dhh1128 regarding Trust Spanning Layer (DIDComm, etc):

1. In DIDComm, protocols are used to expand the basic core features of DIDComm (Trust spanning layer). Should most of these protocols be defined as trust tasks? (See https://didcomm.org/search/?page=1) to minimize the Trust Spanning Layer footprint?
2. Where should the line be drawn between L2/L3 layers? Should a Trust Decision Trust Task just define which DID-based connection to use, what to send as an input and what to expect as return value (similar to current DIDComm protocols)?

[a-fox]

I see currently two options on how to handle Trust Decision queries:

1. Trust Task instructs the business applications to query the trust source directly. This would mean that the role of the Trust Task is to define how trust decision context is defined and protocol-level support is Business application's problem.
2. Trust task builds a trust decision query and instructs the trust spanning layer to execute it.

The key problem is: When is it reasonable and useful to use the Trust Spanning Layer? Should / can Trust Decisions be made based on information from out-of-band queries?

[andorsk]

From @jacqueslatour:

• here's an example of a IETF standard for TLD registry https://datatracker.ietf.org/doc/rfc5730/
  Scott Perry:
• Governance more communication and involvement with the trust registry.

[andorsk]

Dima: Trust management vs. Trust Discovery

[dhh1128]

@a-fox wrote:

Questions to @talltree & @dhh1128 regarding Trust Spanning Layer (DIDComm, etc): In DIDComm, protocols are used to expand the basic core features of DIDComm (Trust spanning layer). Should most of these protocols be defined as trust tasks? (See https://didcomm.org/search/?page=1) to minimize the Trust Spanning Layer footprint? Where should the line be drawn between L2/L3 layers? Should a Trust Decision Trust Task just define which DID-based connection to use, what to send as an input and what to expect as return value (similar to current DIDComm protocols)?

Yes, IMO most of these protocols should be defined as trust tasks.

Re. where the line should be drawn, I'd like to propose the following tentative framing, which I hope to expand upon in a future TSPTF meeting:

Layer 3 is task-oriented, whereas Layer 2 is relationship-oriented. That is, Layer 3 is about getting work done, whereas Layer 2 it is about providing a generally trustworthy context (a relationship, if you will, though it doesn't necessarily have all the trappings of a human relationship) to contextualize and secure any number of higher-order tasks.

A trust registry is used to answer the question: "Is this piece of evidence grounded in conventions and entities that I consider trustworthy?" [[Edit: And it also answers other questions -- see Darrell's comment just below.]] This word, "grounded" may make us feel like we are talking about about something foundational -- and indeed, trust registries ARE foundational. But what a particular trust registry is foundational TO is one or more tasks, not to a relationship in general, or even to the set of all potential trust tasks in that relationship. Relationships -- and the trust we want to achieve at the trust spanning layer 2 -- are at least potentially multi-purpose.

If Alice wants to apply for a loan, she presents evidence of her credit-worthiness to the bank, and the bank uses a trust registry to decide if the evidence has a basis that it likes. But whether the bank decides to offer a loan, or to withhold it because Alice is asking to borrow too much for her income, the trust registry's relevance has a TASK scope (it's foundational to deciding whether Alice's credit rating evidence is solid in the context of a specific loan application). A minute later, when Alice wants to open her safety deposit box, the trust registry is irrelevant. A month later, when Alice applies for a job at the bank, maybe she presents VC-based evidence of her qualifications, and different trust registries come into play. Or maybe not. A year later, when Alice applies for a loan again, the bank has no question about the usefulness of the evidence that was presented in her prior loan, but it consults the original trust registry again, with a different goal from a different task. These are clear indicators that the trust task interaction itself is a layer 3 thing -- a trust task -- rather than a layer 2 thing -- relationship underpinnings and task preconditions.

[trbouma]

I concur with @dhh1128 and will try to re-express in my own over-concise fashion
As for the overall model - Layer 3 and Layer 2 are consistent with what I am thinking:

A quick mapping:

Layer 4: rights-oriented (this is the charter layer)
Layer 3: task-oriented (this is the covenant/contracts layer)
Layer 2: relationship-oriented (this is the channels layer)
Layer 1: commitment-oriented (this is the commitments layer)

The trust registry operates at Layer 2 and answers the general question:

Is what I am relying on is accurate/legitimate and based on intentions of: 1) the rules of a governance framework, and 2) an authorized action/assertion of an actor based on those rules?

IMHO, answering these two questions are the 'grounding' required for relying on trustworthy context to carry out a trust task.

Of course, we can never know the true intentions of a human being, or group of human beings - that will never be so, but we can create a capability that those intentions don't get morphed, mutated or misunderstood as they pass through a technical infrastructure.

In the end, I think we can come up with a simple abstraction. I've realized that the power of a DID is that it can represent the intention of an actor and that the DID can exist across many trust contexts having different authorities within those contexts. Furthermore, a trust context can also have its own DID, which can represent the intentions of a governance framework, and be used to authorize an actor (by means of their DID) within that context. Finally, a trust context DID can exist within an even larger trust context, that can authorize the trust context DID as well. A recursive/hierarchical/nested/scalable model, however you would like to call it.

Anyway some more food for thought.

[darrellodonnell]

This helps a lot.

[darrellodonnell]

@dhh1128 a Trust Registry also answers the question "what do I need to participate in this ecosystem?". schema, credential types, comma layer, conformance tests, etc.

[andorsk]

@darrellodonnell started converting some of your OAS into an actual spec here

[a-fox]

@andorsk - its 403 forbidden

[andorsk]

@a-fox it requires you to be a signed in user. changed perms here so no sign in required.

[darrellodonnell]

updated diagram...

[neiljthomson]

Tool used? Model available to copy and provide variation?

[darrellodonnell]

PlantUML - will get it into GH today/tomorrow.

current version:

`@startuml
skinparam groupInheritance 1
page 1x3

title Trust Over IP Trust Registry Protocol v2 Early Exploration

' object Error
class BaseRegistry {
EGFURI
}

class Query {
AuthoritativeIssuers()
AuthorizedVerifiers()
RecognizedRegistries()
ApprovedWallets()
}

class Lookup {
DIDMethods()
CredentialTypes()
CredentialSchema()
PresentationRequests()
Overlays()
Resources()
Roles()

}

' inheritance

BaseRegistry <|-- Query
BaseRegistry <|-- Lookup

package QueryDataObjects {
object Issuer
object Verifier
object Wallet
object Registry
}

package LookupDataObjects {
object DIDMethodList
object CredentialTypeList
object CredentialSchemaList
object PresentationRequestList
object OverlayList
object RoleList
object AssuranceLevelsList
object Role {
rolename: string
}
object DIDMethod {
didmethod: string
}
object Overlay {
overlayIdentifier: DID
overlayPayload: string
}
object AssuranceLevel {
AssuranceIdentifier: string
AssuranceName: string
'TODO multilingu
}
}

Query::AuthoritativeIssuers --> Issuer
Query::AuthorizedVerifiers --> Verifier
Query::RecognizedRegistries --> Registry
Query::ApprovedWallets --> Wallet

Lookup::DIDMethods --> DIDMethodList
Lookup::Roles --> RoleList
Lookup::Overlays --> OverlayList

RoleList o-- "0...n" Role
DIDMethodList o-- "1...n" DIDMethod
OverlayList o-- "0...n" Overlay

@enduml`

[neiljthomson]

Doing Master Classes on PlantUML next week?