# TATF May 19 2022 - Discussion on Tech Arch document sections 5.1, 5.3 & 5.6

This inlcuded discussion of key terms (for a Tech ARch glossary) and sections 5.2, 5.3 and 5.6

Table of Contents Trial

* [Different Classes of Identifiers](https://hackmd.io/cRNAX1ImRGOucds_ntXI2Q?view#Different-classes-of-Identifiers---Autonomic-amp-non-Autonomic)

## May 19 2022 Afternoon TATF session

From APAC Meeting (recording): https://zoom.us/rec/share/fUgrF0JT3ZHuwaGwlSUZF53TyJejd5SVpxpu7w5GrCoaxlDHUORhC3pEt4n8VXTu.I_44Ba5al1tODnyn

- start of discussion (in recording) 4:36

**Participants** - Wenjing Lie, Sam Smith, Judith Fleenor, Neil Thomson

### ToIP Technical Architecture Glossary

**Action item**: a terms wiki/glossary (associated with the Tech Arch Spec) is required to provide summarized and detailed definitions of these term (and other terms in this transcript) and be a general practice when terms have a very specific ToIP/SSI or other context meaning that is vital to ToIP/SSI.

The following is a list of glossary terms (for the above glossary) germane to this document/discussion

- **Autonomy** -  the quality or state of being self-governing
- **Autonomic** - acting or occurring involuntarily - e.g. autonomic reflexes (such as breathing)
- In the SSI case - Autonomic implies decentralized - can operate on their own without central control
- **Autonomous** - able to act independently
- In the ToIP SSI and identifier control discussion. Autonomous applies to the entire stack (e.g. OIDC Identity Controller)
- **Authenticity** - The SSI definition (of an Identity, Data) is verifiable traceability to the service that produced the identity. In SSI, that is achieved by cryptographic signing of a hash (e.g., of a message)
- **Confidentiality** - control of access to sensitive personal information . For exampl: PII attributes or personal records
- **Cryptonym** - cryptographically protected/self certifying identifier
- **Decentralized** - <def'n required, with emphasis of principles vs centralized>
- **Hour-Glass model** - <Def'n req'd>
- **Identifier vs. Identity** - An *identifier* is a UID, which is necessary for machine/machine trust (e.g., required to establish DIDComm channels between entities). *Identity* (of a person or thing) is established via Verifiable Credentials (VCs), exchange via a communication channel
- **Integrity** - Integrity is a subset (consequence) of SSI **Authenticity**. Authenticity (of a message in SSI) is established via a signature(s) (a cryptographic hash using the private keys of the identifier), which provides **Integrity**. The side affect is you also get non-repudiable authenticity.
- **Interface (API)** - <def'n required - in contrast to Protocol>
- **Non-repudiation** - (from KERI WP v 2.6.0)
A digitally signed verifiable statement provides two additional trust
properties, these are integrity and non-repudiability. **Integrity** means the statement has not been tampered with since the signature was created. One can trust the statement was made as received. **Non-repudiability** means that no other entity besides the holder (controller) of the private key could have created the signature. This means that the holder may not repudiate the statementwhile maintaining that they have sole possession of the private key.
- Non-repudiable is also **Authentic** - Any digitally signed verifiable statement (Verifiable Credentials, data blocks, contracts, etc.) is also **Authentic**
- **Non-repudiable identifier** - is one that uses a cryptographic root of trust and requires proof of ownership (of the private key) by the **holder** (identifier presenter) to the **verifier**. The verifier can also confirm lack of tampering and verification of the identifier via verifying with the (holder provided) public key.
- **Party** - <def'n required for ToIP> - for now see eSSIF-Lab version [Parties, Actors and Actions](https://essif-lab.github.io/framework/docs/terms/pattern-party-actor-action)
- **Protocol** - <def'n required - with emphasis on constrast to "interface"> is an interface across a public or private network (in contrast to within a network node)
- **Pseudonymous** - a name, term or descriptor (for a person or thing) that is different to their actual name
- **Pseudonymous identifier** - an identifier used (primarily for machine trust) that is not the same as the entities name. A phone number is a pseudonymous identifier
- **Privacy**
- Protection of personally sensitive data
- Freedom from interference and unauthorized observation (surveillance)
- See also - [Privacy, Authenticity and Confidentiality](http://news.windley.com/issues/privacy-authenticity-and-confidentiality-technometria-issue-44-1054351) by Phil Windley - based on a talk by Sam Smith
- **System** - <def'n required - in terms of a collection of services?>
- **Service** - <def'n required>
- **Verifiability** - to be able verify an assertion claim (e.g., ownership of an identifier, that a verifiable credential was issued by a registered issuer)
- **Verifiable non-repudiation** - is a strong form of verification. Where the act of verification confirms non-repudiation.

### Section 5.1


What are the precise meanings for verifiability, authenticity ( & integrity), confidentiality and privacy in this context?

In the classical IT the golden triad is Confidentiality, Integrity, Availability. Yet confidentiality and integrity are not authenticity. Availability is no longer important as everyone knows how to do that. Integrity comes for free (w SSI/KERI) if you have )crypto-secured) authenticity.

The new triad is authenticity, confidentiality and privacy. Confidentiality is actually easy if you have end-to-end pipes between parties who control the encryption. Authenticity and Privacy are the "hard things".

Trust is established through a series of steps that must comply with the three elements listed above (verifiability, confidentiality, privacy)

1. A communication channel is created between entities via Self-certified identifiers.
2. The entities then exchange Verifiable Credentials related to the type of credentials required for the type of transaction(s) the parties wish to participate in, which each party verifies.

Trust is not achieved until all the required types of credentials are verified.

### Section 5.3



### 5.3.1? Identifier

Uses Self (Cryptographic) Certified Identifiers. Detailed properties: pseudonymous, self-governed, autonomic and autonomous, cryptonyms.

An identifier can be proven authentic because you can associate the identifier with the controller of the identifier. Controller in this case are both the party/actor/entity controlling the identifier, plus it comes from and how it's generated. That includes self-certification and control of the private keys.

The original concept of self-certifying an identifier had to do with a PKI pair, but that didn't include the ability to rotate the keys underpinning the identifier - which is the new thing - a persistent self-certifying identifier, which makes it a self-governing autonomic identifier, which is very different from the 1990s concept of self-certified. This is where understanding the distinctions between autonomic and autonomous, which are subtle, but non-trivial.

Verifiable non-repudiation is the the most important thing (vs just verifiability).

### Autonomic vs. Autonomous

Enter the distinction between autonomic and autonomous computing, which is critical to understanding why SSI using ***autonomic*** self-certifying identifiers can provide end-to-end verifiability required for distributed systems vs. ODIC ***autonomous*** identifiers, which are centralized (with identity providers).

An autonomic system is like the breathing which takes place whether you consciously choose to breath or not. Breathing continues whether you are asleep or unconscious. So you can override the "hardwired/default" behavior, but the default behavior will resume once you stop directly thinking about it.

An Autonomous system that is not autonomic requires constant attention (such as OIDC AuthN/Z) and does not have a default behavior that will verify identity without (identity) controller input.

So autonomic and autonomous are both self-governing, but the difference is guaranteed default behavior for trust level actions (such as validation/verification) for autonomic systems, but always subject to controller direction for non-autonomic autonomous systems.

Autonomic means a self-governing system (without requiring outside control to operate, including (key, scoped) behavior guaranteed to not allow outside control, including verification and possibly others), where autonomous merely means independent (which allows outside control/overrides and does not necessarily have default (guaranteed) default behaviour for verifiability, etc.).

***Autonomic** identifier management (verifiability in particular) is required for distributed identity management.*

The bottom line is trust:

- An autonomic identifier control can be relied on for consistent behavior for key behaviors. For use in SSI in a decentralized system, autonomic behaviour must be "observable" (verifiable) to be trusted.
- An independent/autonomous control, with no guaranteed non-overridable/autonomic behavior for vital functions does not provide the same level of trust. Observability is not guaranteed.

An essential point here is that how an identifier is controlled is not a requirement for interoperability (e.g. SSI/OIDC), but interoperability does NOT mean that the same level of trust exists for identities from SSI vs. OIDC.

OIDC can create it's own identifiers and interoperate on exchanging Verifiable Credentials, including with SSI systems. However, that does not mean that OAuth/OIDC, which does not use autonomic components like identifiers, issuers/holders/verifiers checks and balances using autonomic identifiers and related aspects, deserves the same level of trust as SSI and the ToIP stack.

Side note: OIDC has become the de-facto Federated Identity mechanism, but it is primarily a centralized vs. decentralized identifier approach. <ins>OIDC SIOP and the adoption of VCs provides organizations a graceful migration path to decentralization via SSI.</ins>

A gating factor for SSI (that has been realized in multi-block chain trust domains) is that it is very difficult to move between (effectively centralized) trust domains, unless identifiers have a high degree of (autonomic) autonomy.

To achieve decentralization, the properties of a decentralized identifier is that they have the properties and verifiability (and autonomic behavior) to cross trust domains.

Key finding: *the Tech Arch Spec needs to define a glossary/terms that define the key aspects of SSI identity, including required autonomic behavior.*

Key observation: *not all DID methods (API sets) support autonomic identifiers*.

What distinguishes SSI/Decentralized Identity is defining autonomy at the (holder as controller) level. That the implementation of the identifier internals supports autonomy of the controller (holder) of the identifier.

The issue here is "loci/locus of control".

### 5.3.2? Common Message Format

Communications is always about the message. Confidentiality, authenticity, privacy is about communication (the message) not the identifier. A message is authentic because it can prove it is controlled by the identifier and whether or not you can associate the identifier with an party/actor/entity.

### Section 5.6 Interoperability

5.6.1 Interoperability between Decentralized Identifiers

- Which is about SSI/Self-Certified Identifiers (SCI)
- Defined as a self-governed, autonomic, pseudonymous cryptonym. Control of an identifier is proven by signing a message?

5.6.2 Interoperability between Decentralized and other Identifiers

- Which is about the interaction of SCI and other (e.g., OIDC) identifiers

Discussion

- 5.6 needs to provide a clear description of what properties, requirements and features distinguish SSI/Self-Certified Identifiers (SCI) from from non-SCI Identifiers (e.g., OIDC)
- The core illustration/model/diagram for 5.6.1 is the generalize reference architecture (below), where the end-systems communicate directly (in SSI)


This is in contrast to OIDC where end-systems (Relying Party and End User) communicate via a centralized ID controller (Open ID Connect ID controller) - below. The difference between these two models is core to describing *5.6.2 Interoperability between Decentralized Identifiers and other Identifiers* (with OIDC as a prime example).


The traditional controller of identifiers has been via a centralized "identity provider" (IDP), not the individual/holder, with the holder's rights to make identifier change requests to the IDP governed by the IDPs policy, which can deny a holder's requests. Traditional identifiers are controlled, but they are not "authentic" by the ToIP Architecture definition of Authentic.

**Example**: phone number portability in early years was subject to a customer of telecom A being "in good standing" to be allowed to port their number to telecom B, vs. an guaranteed right to transfer (today).

The binding between the controller (individual) and the identifier (management/control "machinery") is very tight. That level of control cannot be delegated without either losing control or doing so under very prescribed legislated/legally mandated conditions (e.g., via a digital (identity) notary). This about "locus of control".

### Delegating Identity/PKI management to 3rd parties

Delegating maintenance and managment of an identifier is not the same as giving up control.

An individual's delegation of management of their identifiers to a 3rd party requires that (to retain control of the identifier) the 3rd party guarantees (preferrably crypto-guaranteed) that key aspects of identity management that a 3rd party cannot be overridden. Such a service is strictly a "holder in trust" and a daily maintenance and storage (replication, backup, etc.) service - essentially rented "identifier plumbing".

In other words, "delegation of control" by an individual of their identifier and identifier management to a 3rd party can be allowed, but only if the individual has the right to withdraw consent and move control of their identifier to another 3rd party. Again, the key issue is absolute control over your identifier(s) and identifier management.

Enter the portability of phone numbers.

### Identifiers - Loci/locus of control and portability - phone number analogy

Most Identifiers you only "rent" from a centralized authority, which they can revoke at any time.

An identifier that's not portable solely under your control, then it's not autonomous, and you can't prove ownership.

Back to the phone number example: A phone number could be portable, but that may be at the discretion of the identity management, which means it is not autonomous. For example, if the number is portable only if you are a "member in good standing" (which is the way that phone number portability legislation reads in many countries), then you don't own it and that's not autonomous.

So while it is easy to generate and register an identifier, the difficult part is maintenance, including identifier/PKI (keystate) history, which you can delegate, but without sole control, that identifier is NOT autonomous. And that includes owning the history (all the keystate events).

And the end result is Blockchain (for the history) or something that meets the same requirements (e.g., KERI infrastructure)

### SSI/KERI and Open ID connect support for VCs and interoperability with SSI

Open ID Connect (OIDC) supports the Self-Issued OpenID Provider (SIOP) spec and OIDC use of Verifiable Credentials. Compare and contrast vs. SSI and how in OIDC and OIDC identifiers interoperates with SSI systems and SCI identifiers.

Comment - when some key OIDC standards drivers talked about take a VC and putting in an OIDC token (access token). Does this not lose provenance (able to verify a VC against a (Root-of-Trust) ledger for signature by a (trusted) issuer)?

(using the OIDC illustration shown earlier) - This illustrates the workflow in OIDC here for authentication (AuthZ) authorization (AuthN). For SSI the interaction for establishing trust is peer to peer (Holder, Verifier). For OIDC, the Relying Party and End User are SSI (architecture) "End Systems".

OIDC requires a centralized (OIDC) identity provider that confirms identity and creates id\_tokens and access\_tokens (carries AuthN content). The OpenID Provider is a middle man, which is not under the control of either the Relying Party or End User, so it is not "self" sovereign.

Basically, it's a governance thing. If the Open ID Provider is governed by the end-systems, then it's just a service. But if the Open ID Provider governs the process, then the end-systems are not in control and SSI is all about "locus of control".

Some OpenID Providers argue that they are the equivalent of a block chain and they are just another service.

The argument from some vendors (a claim also made for IAM) is you, the user, control the service. We have an open API and you get to control and you can extract your data, so you have autonomy over your identity.

There is also the argument is that Open ID Providers are well behaved, and you are not losing anything, but the SSI argument is that you do not need this "middleman". The argument is also that Open ID Providers regulated to ensure end-system/user control, but that's not the same as the core design (SSI) eliminating the need for a middleman.

So what Open ID is claiming (or could claim) is that through (regulation enforced) behavior of the Open ID Provider, then they meet the SSI Reference Architecture requirement of end-system/user control. Are they right?

They may be able to comply with the governance/compliance requirements, but that doesn't make Open ID Connection a "native" self-sovereign system.

### SSI, non-SSI and end to end trust

Sam - I don't think you can assign an end-verifiable root of trust that is portable without using sufficient cryptographic entropy in the identifier. Any attempt to use a non-cryptographic strength identifier, at some point will eventually run up against some mechanism that prevents you from having end to end verifiability and you will have to trust some third party, which is not self-sovereign. I can't prove it (yet), but my intuition tells me that.

So for now a better argument (and supposing non-cryptographic self-controlled identifier is possible) is to state that our (ToIP/SSI) belief is you need to use SSI based identifiers and that if someone can come up with an alternative that meets the security and proof requirements, then we can open the spec up to that compliant solution. But currently, such a mechanism doesn't exist.

Bottom line, SSI is a simpler solution with more robust "cryptographic entropy" and end-system control that adapting existing non-SSI identity solutions. When in doubt, the simplest solution is the better standard.

Note that not all SSI implementations are end-verifiable (end-to-end-verifiable). There are known cases of DID Methods that are not compliant.

### An Enterprise can make non-SSI implementations compliant, but may not be possible on the Internet

Another perspective, when used in an enterprise which can take steps to ensure all the components and middle men comply with end system/user controlling their identity. But's not "out of the box/native" functionality, where for SSI it is. So an enterprise can make it compliant as they fully control the environment, but that level of control does not exist on the general internet, where with SSI, as it's self-sovereign is by design, it can guarantee end system/user control.

Protocols are control neutral. So OIDC in complying with the requirements of the SSI end to end protocol does not care if there is a middleman that is part of that end to end protocol. It may not be ideal and may take a lot more work to secure, but it can still be compliant.


To complete actual transactions, you need the upper layers as well, which for SSI includes trust/verification as part of the exchange of VCs (holder/verifier/issuer with the ledger), for which an OIDC solution may or may not comply. And end systems may or may not trust DIDs/Identifiers (and tokens, or VCs embedded in tokens) from an OIDC system.

An anticipated problem is that smart people provide emulation of SSI with non-SSI technology, claiming they are fully SSI (vs an emulator), which blocks adoption of actual SSI. This can also be problematic long term as vendors and customers using the emulation route potentially block SSI spec/tech evolution where a feature cannot be emulated in their technology.

### Compliance is a combination of solition properties and compliance suite tests

Reference architecture implementation compliance requires (at least) that:
- The specification qualify the properties (requirements, features) of end-verifiable, secure cryptographic identifiers (that are self-controlled), **but not any particular implementation**.
- Developing compliance test suites (which is something OIDC does for all theirstandards).

### Different classes of Identifiers - Autonomic & non-Autonomic

Example of Self-Certified Identifiers (SCIs) and work email. I have a SCI (personal). At work, I'm issued a work ID (corporate email address), which is the ID I use to communicate as an employee. If I write an email it is from me, in a role within my employer, which is also an email from (a representative) of my employer.

Sam - this is a "community identifier". Sam has a paper called Universal Identifier Theory, that you start with SCIs. You can link those SCIs with group or community identifiers that are "local" (e.g., at work).

While useful, the Community identifier (work email) is not end-verifiable. That only applies to the SCI "class" of identifiers.

So the SCI and company email are different classes of identifiers. An SCI is an autonomic identifier. Any other type of identifier (such as as a (simple) email address) is not autonomic. There needs to be clear understanding of the difference in the properties of autonomic and non-autonomic.

*Cationary note:* there are those who would prefer that all identfiers are of the same class/equivlanent, as that allows 3rd parties (vs. end-user) to assert control of and over identifiers.

### Example of standards and emulation/equivalents of standard X by standard Y

An example of claiming compliance for what is actually different; **Open Source standards Copyleft and Apache**

Copyleft allows free use of source code, but any improvements or extensions must be contributed back to the originating Copyleft project (reciprocal licensing). Apache does not have the reciprocal requirement. The Copyleft argument is software licensed under copyleft provides for a free license, so it's equivalent to (Apache) Open Source. That is not to say that reciprocity is bad, it's just not the same terms as the Apache Open Source license.