Trust Registry - Terms and Concepts

[neiljthomson]

Purpose - to capture and define (or refine) new terms and concepts that apply to the ToIP Technical Architecture, components in the architecture, etc.

Format:

• Term - single discussion post - add new terms for which a definition does not exist
  • reply to the post to add a new term
• Term + Definition - a single discussion topic for each term and a draft definition
  • reply to provide comments, proposed changes, etc. to the definition or to add additional description material (e.g., links to reference)

[neiljthomson]

New Terms

• add new term by replying to this post

[talltree]

@neiljthomson Why are you indicating that "Trust" might be optional? IMHO we should not be defining plain English words like "context" and "decision".

Also, we should not be using capitals unless the term is an actual proper noun (or acronym).

[neiljthomson]

The use of brackets was to provide a "frame of reference" for the words (e.g., "context" in an SSI "frame of reference"), can drop those.

Ditto use of capitals

[neiljthomson]

Updated List (note - lower case - no brackets)

• trust registry
• trust list
• trust ledger
• trust directory
• trust graph
• trust decision
• trust query - aka trust criteria query, trust test
• trust criteria
• trust context
• trust decision graph
• governing authority - aka authority
• trust ecosystem
• administering body
• governance framework - aka ecosystem governance framework
• governance role
• jurisdiction (and how interplays with ecosystem)

[neiljthomson]

Some key points, leveraging from comments @talltree in the APAC call 2 Mar 2023

• The word/phrase used in the term is secondary to its meaning.
  • A term and its meaning need to be commonly understood and used consistently.
• Each term/concept needs to be described individually, and, perhaps more importantly, what distinguishes term A from B.
  For example, "trust collections" (to use a generic term) of various types are discussed in this space and need to be understood if they are alternate names for the same thing or are different and for what reasons:
  • term "collection" types: list, registry, ledger, directory

[neiljthomson]

Adding

• system of record
• verifiable data registry

Note (from @talltree on slack) - system of record is different from a verifiable data registry. As you say, the former can use any method the operator chooses to secure the repository, so the data in the system of record is authoritative. In the latter case, all the entries in a verifiable data registry are digitally signed and thus are cryptographically verifiable as being authentic. However it is entirely possible that a verifiable data registry is NOT the system of record for a particular set of signed data (such as a trust graph) because the verifiable data registry is just serving as an external repository or discovery mechanism for that signed data.

[neiljthomson]

Term: Trust Context

Questions:

• What information is included in a Trust Context?
• What would a specification look like to define a Trust Context, including mandatory, recommended and optional context information?

Definition:
Context defines the rules for a Trust Test which is applied during Trust Spanning Protocol requests and responses, producing a *Trust Result. Some examples:

• A given Ecosystem Governance Framework and Jurisdiction can specify:
  • The type of trust models it uses (e.g. Issuer/Holder/Verifier) vs (GAIN's) End User/Identity Information Provider/Relying Party model
  • Cryptographic algorithms and configuration requirements
  • Identifier type (e.g., AID, SAID, DID)
    • DID Method(s) supported
    • ...
  • ...

[talltree]

My view: this could turn into a giant rathole unless we constrain it the way we did in the ToIP Governance Architecture Specification V1.0 spec: the relevant trust context(s) are defined by a governance framework (GF) using DID URLs.

Trying to define what must or must not be in a particular GF is far beyond our scope or means. My point is that it doesn't matter: in its GF (which is itself a trust context), the governing body can specify the requirements for any other trust context it defines (or that others define) using a DID URL. It can include that DID URL in a verifiable credential or any other trust task protocol or trust spanning protocol message. Then any verifier can use that DID URL to identify the applicable trust context and apply its own policy to make its own trust decision.

To the extent that a governing body decides to express some or all of its GF as a machine-readable GF (MRGF), then that MRGF can also be assigned its own DID URL and now the verifier can run verification software that can resolve, download, verify, and process that MRGF against the verifier's own policies to make a trust decision.

That's all we need to say about it. Everything else is out-of-scope for the Trust Registry Protocol.

[neiljthomson]

"giant rathole"? Or some key requirements and workflows that need to be addressed? I will have input early next week.

PS: that's a very good description/articulation of the job that a GF needs to do and how that might be packaged and communicated, including that it may put that in machine-readable form. I need to do some homework in the GATF and other groups, but I don't recall that being described or diagrammed.

And I would note that this fits well with the Diagram that @darrellodonnell put up in the TAWG Plenary yesterday

[neiljthomson]

PPS: Looking at Trust Checkpoints in the flow from initial TSP communication (A calls B) to the point of completing transactions with highly sensitive data suggests there are a number of checkpoints in the Layer 2->3->4 flow each of which may need a TR (or variation) . Again, I will have input next week.

[trbouma]

A related diagram I am working on for conformity assessment and accreditation

[andorsk]

Question From @andorsk : Is registry synonymous with list?

Discussion on Friday:

• Registry is synonymous with list.
• Dima is saying could be a tree. Pointed to discovery as a super important function of a trust registry.
• Jo: Registry implies that it's curated by a Regulator. This is what happens in Government scenarios.
• Drummond: I would propose that we need to include both “trust registry” and “trust list” in our TSWG glossary — and that both need to be part of the mental model we need to build.
• Dan: Dictionary says public ledger
• @darrellodonnell :
  • Term "trust list" #82
  • Term "Trust Registry" Definition needed #83
• Dan B: a quote from ISO TC 211... "What is a registry? Simply put, a registry is a list, and the list is maintained by a registrar separately from a standard." Also, from ISO 11179-6 A set of files (paper, electronic, or a combination) containing the assigned data elements and information.

[trbouma]

The Pythonista in me says that a trust registry can be expressed a list (or set) of tuples with signatures:

trust_registry_alpha = [(a,sig_a), (b,sig_b), ... (z, sig_z)]

Each tuple '(a, sig_a)` represents a binding authority that is the outcome of a given governance

Then, a higher order trust registry is, in turn, a list or collection of trust registries:

higher_order_trust registry = [(trust_registry_alpha, sig_alpha), (trust_registry_beta sig_beta), ...  (trust_registry_omega sig_omega)]

This structure can be recursed up to a 'root authority' which needs to be formally granted by a supreme body or actor (queen/king, parliament, social committee, etc.) It can be assumed that these bodies/actors control the generation of signatures.

root_authority = [(higher_order_trust_registry, sig_root_a), ... ]

Of course, the real-world complexity lies with what a,b,... actually represent - that's the hard part.

As I write this, I realize that these are actually sets (no duplicates) so, it is a trust set:

higher_order_trust registry = {{(),()}, {(),()}}

[neiljthomson]

intent

This term has been included in some discussions, presumably taking place in the interaction between "Bob" & "Alice", or maybe not.

Looking for input/opinions on what "intent" is, whether it changes with moving up the tech or protocol stack and how it is different from a Layer 4 transaction request (e.g., "I'm interest in buying your car")

[neiljthomson]

Reviewing the use of intent and intention in both Trust Registry and Trust Spanning Layer GIT, intent is a dangerous word as it has many meanings (merriam-webster) and in those discussions, people are using all of those meanings, in one case with several of the meanings in the same posting.

Suggest using the following more precise words

• purpose (e.g., the intent of Bob contacting Alice) - what is the purpose of the interaction?
  • this might be included as a subject - in the email title sense of subject - for Bob to specify in a connection request to Alice.
• scope (e.g., the intent of layer 2 vs layer 3) - what is the scope of responsibilities of each layer?
  • planned scope what is the eventual intent (planned scope) for layer 2?
• meaning, significance

[neiljthomson]

operations

@darrellodonnell brought this "on to the page" last week, asserting that "operations" is a missing component to the Tech/Governance stack, which are specifically scoped outside of the ToIP Tech Arch and Governance discussions.

So - asking for input on what separates operations from what the Tech/Tech Arch and Governance scopes.

Observation - while operations are out of scope, do operations impact components and services that need to be part of the Tech Arch?

[darrellodonnell]

My comment was that while ToIP is focused on a dual stack that links Governance & Technology, we need to remember that ToIP is not about Operations.

[mathieuglaude]

Authentic vs authoritative (apologies in advance if this discussion has happened)

These two words were discussed in last week's TRTF call, but I must admit I left confused a bit.

1. What's the difference between both of these words?
2. Do they have a relationship?
3. Does one supersede the other?

[darrellodonnell]

I am sure that others will be do this better than I at clearing this up, but here goes... We're using the term "authoritative" and it is contextual. You may determine that you need to use an authoritative source for a government identity document. In some places (e.g. the EU with eIDAS2) you may be able to rely on an "authentic" source where one exists - AND where that authenticity is defined (e.g. again, the eIDAS2 framework). However, for global coverage you're likely going to need other authoritative sources AND define why you feel they are authoritative. It is handy that eIDAS2 has defined "authentic" but that's just one dimension. We used "authentic" in the terms of the eIDAS2 identity ecosystem. Governments are considered authentic sources. That can mean it is deemed authoritative in my context - but the EU can't tell me that. I decide that. They don't supersede each other. An authoritative source can be authentic, but what "authentic" means is subject to definition/interpretation. Depending on what other ecosystems you're hooking into "authentic" may or may not have meaning. Does that help?

…

On Mon, Mar 20, 2023 at 11:29 AM Mathieu Glaude ***@***.***> wrote: *Authentic vs authoritative* (apologies in advance if this discussion has happened) These two words were discussed in last week's TRTF call, but I must admit I left confused a bit. 1. What's the difference between both of these words? 2. Do they have a relationship? 3. Does one supersede the other? — Reply to this email directly, view it on GitHub <#79 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFHWB5IZNQ2G5XH4E37HTLW5COYHANCNFSM6AAAAAAVMLY7TU> . You are receiving this because you were mentioned.Message ID: <trustoverip/tswg-trust-registry-tf/repo-discussions/79/comments/5373053@ github.com>

[mathieuglaude]

My understanding on verifiable is that I can achieve it cryptographically in my own self-sovereign way without talking to the source (or anyone in that matter). Is authentic the same thing? If so, that clears things up for me. If not, I remain confused :)

[talltree]

I am proposing that we begin using verifiable instead of authentic (as in the examples above) precisely to clear up that confusion. But I am just one voice in the TSWG terms community. Only the terms community as a whole can come to consensus about use of any particular term.

Can I take it that as one member of that community, @mathieuglaude, you would be in favor of that proposal?

[mathieuglaude]

Yes, based on what I understand I support this @talltree.

Does this make sense to you @trbouma?

[neiljthomson]

Verifiable Data (slight mod on the TSWG Glossary in italics) - Any digital data or information that is cryptographically signed in such a manner that it can be independently verified. In the context of ToIP architecture, verifiable data is signed with the cryptographic keys associated with the ToIP Identifier (DID) that "owns"/contains the data - the "data source".

Additional rigour adds the following cryptographic signatures :

• The Role responsible for the processing applied to the data (e.g. data collection administrator)
• The Role responsible for the governance of the data processing

Authentic Data (or any object) - data that has been verified to its "root of trust," an AID controlled by an Authority recognized (can be proved) as the owner of the root of Trust. Data that is presented may have been through multiple stages of processing, from raw data collection to presentation. Those stages (which may be a simple linear sequence or a tree) form a chain. Verifying from the presentation through the chain is an Authentic Provenance Chain, as defined in ACDC, which should be (ideally on demand) traceable to each of the roots of trust for all processing paths.

[neiljthomson]

PS: I've also read/heard opinions that "Authentic Data" also includes it to be verifiably accurate/correct. However, while the English definition of Authentic (Merriam-Webster) includes that it is based on fact, that does not mean it is verifiably accurate/correct. The term (data) Veracity needs to be defined for that.

[darrellodonnell]

It is YOUR decision to accept what is authoritative. You can defer to others as your choice of authority.

On Mon, Mar 20, 2023 at 12:49 Mathieu Glaude ***@***.***> wrote: To re-iterate: An 'authority' makes a decision that something is 'authoritative'. Hopefully the 'authority's' decision about something being 'authoritative' is based on something 'authentic'. But regardless, their decision means it's an 'authoritative' input to inform my own trust decision. Make sense? — Reply to this email directly, view it on GitHub <#79 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFHWBZDERFICW7LSAA7TGTW5CYFJANCNFSM6AAAAAAVMLY7TU> . You are receiving this because you were mentioned.Message ID: <trustoverip/tswg-trust-registry-tf/repo-discussions/79/comments/5373701@ github.com>

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

[neiljthomson]

To add to @darrellodonnell's definition, data may have been crypo-signed by an "Authority" (and their identity known) (from Governance or Data Processing Role). However, it's still your decision whether you consider that "Authority" one that you trust (is authoritative).