Thread by @darrello

Trust Registries help answer the hard questions an ecosystem needs in order to create a whole experience.

a thread - and maybe some sacred cows are at play...

1/

Where do the systems you want to work with go to get the answers to questions like

How do I know can trust

- this Issuer for that Credential?
- trust that Verifier?
- that Wallet App?

2/

hint: that's the Trust Registry Specification v1.0 at the @TrustOverIP Foundation wiki.trustoverip.org/display/HOME/T…

3/

but that was just a start - there are MANY more questions that are just as important. We’re starting the v2.0 of the Trust Registry Protocol Specification to dig in on some of these questions.

4/

questions like...

What credential formats does the ecosystem define?

-- NO - there is no interoperable standard for real-world use of #VerifiableCredentials, so you can't say, "just use W3C Verifiable Credentials".

/5

What DID Methods does the ecosystem support?

and NO - the answer isn't "any DID Method you want" - more on that later

/6

Where is your governance framework codified?

-- NO -"machine-readable governance" is not it,

but there are nuggets of goodness in there

- more at another time.

/7

What do the credentials used in the ecosystem look like - what is their schema?

-- if you think JSON-LD is the answer - that's another NO - a hard NO for many reasons - more later in the thread

/8

How do you support revocation in your ecosystem - if you need it?

most don't - do your homework on that one - i.e. not more later.

/9

How do you do delegation in your ecosystem? Is it baked into your DID Method?

How does someone confirm delegation is still valid (revocation may help - it may not)?

/10

Do you deflect to legal agreement to protect information?

A legal approach is a kick-the-can approach that will work - until it doesn't.

- more later.

/11

How does your ecosystem ensure compliance? Do you have a test suite that proves #interoperability?

NB: Another tweetstorm is likely coming on the myth, legend, and realities of interoperability - it's a topic of its own.

/12

The questions above are being discussed towards the end of this month as we kick off the Trust Registry Protocol Specification vNEXT work. Join us at:

wiki.trustoverip.org/display/HOME/T…

/13

I'm hosting a short webinar to provide the groundings behind that work on 21SEP2022 at 10 am ET: us02web.zoom.us/webinar/regist…

/14

I'll get the link to the recording shared here when it is done. It should show up here, though: us02web.zoom.us/webinar/regist…

/15

Now, on to some of those "more later" items... first at-bat: JSON-LD

/16

SUBTOPIC: JSON-LD is a powerful tool for semantic analysis. It has a few substantial flaws that make it difficult to use in the wild and hard to build into governance frameworks.

But we can compensate.

/17

JSON-LD promises that you can discover your schema and don't need to define your schema.

Neither of those ideas (discover schema & define schema later) helps create robust and resilient systems.

/18

minor aside: JSON-LD as a schema definition felt wrong, but I couldn't define my concern for a long time. A respected colleague casually pointed out that it mixes syntax and semantics - and that's my issue right there.

/19

back to the JSON-LD line - the feature of "you don't even need to define your credential schema in advance" is not good. It is a recipe for complexity bombs.

/20

If you think JSON-LD is magical because I can ingest data with a schema that I don't know yet, you haven't moved enough critical data across multiple, uncoordinated domains (most good uses cases are complex).

/21

A credential can carry its schema when you use JSON-LD. While powerful, it doesn't help adoption - it makes it complex.

There is a simple solution: put a copy of the schema in a Trust Registry as a reference.

/22

and developers don't want the complexity - when it adds no realizable value.

see: github.com/SmithSamuelM/P…

"JSON Schema Already Won the Adoption Battle"

/23

SUBTOPIC: Legal Agreements - are an easy out for credential exchange -the idea being that you don't need to have systemic privacy if you can point out legal approaches to create compliance.

It isn't a real solution, though.

/24

Kyle den Hartog provided good input on the idea, but his answer that legal agreements solve the problem is flawed.

It misses the incentives at play.

kyledenhartog.com/response-to-an…

/25

The "it's a legal barrier" argument misses the massive asymmetry in the market.

The COST of not being compliant (fines & reputation impact) appears large, but it isn't.

A Cost-Benefit analysis fails to capture the dynamic.

/26

A COST >>> Benefit concept is wrong because you have a PROBABILITY of getting caught, multiplied by the probability of prosecuting, which nets out to be a vanishingly low number.

Even the smallest benefit is attractive.

/27

Cost <<<< Benefit in reality. A large and public fine that is rare is not a deterrent for many.

/28

The legal agreement answer also misses that presenting too much information is inherently bad as many system actors are not a party to the legal frameworks (or are unenforceable in reality).

/29

Using the over-used driver’s license - showing an address, full name, etc. of a person when it isn't required.

/30

The bad actor - say a bouncer that floats around bars - doesn't have the same scruples. A privacy law violation won't deter the bad actors.

The solution is don't make it technically feasible. Don't overshare.

/31

SUBTOPIC: DID Methods aren't all the same...

Sure - it should be your choice what DID Methods you want to use, but that statement doesn't stand alone. As a Verifier, I have a choice too.

/32

DID Methods are not all equivalent. There are a few dimensions to consider:

Popularity/Market Penetration, Structural, and Dogmatic.

/33

DID Method Popularity/Market Penetration - As the use of DIDs grows, we will likely see a power law distribution with a small number of DID Methods.

/34

Verifiers will not adopt "just any DID.” There is enough variation that this isn't happening and won't for some time. Even a tiny amount of work to "just add this one" is enough to be a blocker - and the work isn't tiny.

/35

Structural - DIDs and DID Documents will continue to evolve and will inevitably diverge. Structural differences in how each method works will create a moving target.

/36

Dogmatic - if your (you/your organization) DID Method is anchored to something radically opposed to my (me/my organization) approach, the technical adoption may be feasible, but social/political support is impossible.

/37

I have likely stepped on a few toes here. For those that I tagged - know this - I have massive respect for you and the hard work you've been doing. I raise these items as unanswered questions with opinions.

/38

I am at a particular place where I am comfortable with them in a "strong opinions loosely held" mode.

/39

In the positive "strong opinions loosely held" approach, which is a leadership mindset that allows us to move forward by making decisions quickly (the strong opinion part), learning and, when needed, change (the loose part).

/40

Somehow, bros have taken it as meaning "I can be a (leader) prick because I hold my opinions strongly" They aren't leaders using a "strong opinions loosely held" approach.

They are just a**holes.

/41

Let's start the discussion and keep being awesome folks!

Cheers,

Darrell

fin

/42