SSI Architecture Stack / Layers & Community efforts

SSI Architecture Stack/Layers & Community Efforts

Session: 10B

Convener: Rouven Heck

Notes-taker(s): Sarah Allen

Tags for the session - technology discussed/ideas considered:

• SSI STack

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Background: about a year ago, a session about SSI protocol stack, industry has evolved,

We reviewed Figure 1: http://github.com/hyperledger/aries-rfcs/blob/master/concepts/0289-toip-stack/README.md

Layer 3: Data Exchange Protocols: Credential exchange Layer 2: DID Comm protocol Layer 1: Public Utilities: Somewhere we anchor DIDs

Many open questions, for example: Where does credential storage live? starting point….

VC Data Model: Verifiable Credential Data Model

CHAPI[1]: Credential handler API

KERI[2]: Key Event Receipt Infrastructure

SIOP?

DIF[3]: Decentralized Identity Foundation

maybe help to agree on the communication between the layers…

“a blockchain is not a blockchain is not a blockchain” — people are calling things blockchains that have neither blocks nor chains,

Trust over IP[4] stack doesn’t include word “blockchain”

We want to abstract Layer 1 ⇒ give it a DID, get back a DID Document

Besides Pub/Private Keys, we need the DID abstraction layer

The schema will have a DID and you will look up the schema referred by the DID

Entity vs Object Identifier

Ideally Layer 3 is also self-contained

Layer 1 ⇒ All about DID resolution Layer 2 ⇒ All about security and privacy Layer 3 ⇒ All about credentials

Layer 3: Data Exchange Protocols: Credential exchange Confused - Layer 3 - for exchanging credential different layer to use. Trying to parse it all.

Over DIDComm - verifiable credential exchange - one thing you can do.

Lots of places not need a high trust credential.

Not necessarily

What does trusted data stored and claims mean?

DIDComm is a secure and private communication protocol. Can make any protocol run over this. DidComm is not a transport protocol.

DIDComm is not about trust, it is about security and privacy. It verifies that communication is from a specific identity, but does not indicate who is behind that identity. Cryptographic trust.

DID provides an assertion of sameness. Meaningless yet globally unique and resolvable.

Layer on what are the attestations of the thing you have just identified.

Proving control over a DID does not itself constitute what we typically associate with "authentication"

Goal: Layer 3 things can use any Layer 1 things

CHAPI constitutes the basis of a secure connection the same way DIDComm does, but I would not classify it as "DID Communication"


Layer 1 seems most clear (description slightly revised)

KERI is actually completely at Layer Two


KERI is a DKMI. Seems like Layer 1.


KERI actually a key management infra, more like layer 2?

Key management is orthogonal — each layer needs storage, needs keys

Maybe Keri isn’t in the diagram, rather it is a support function

“KERI is a way of life
”

Separate Governance from technical initiatives — e.g. Veres One, Sovrin

This framework supports bottoms-up and top-down governance

People can choose which tech and which governance model

The type of governance needed at each layer is very different.

This diagram is super helpful where having examples in each box help us to understand the category. An example trust framework would be very helpful. Modified diagram...

CHAT From the Zoom SESSION:


This diagram is in this doc: http://github.com/hyperledger/aries-rfcs/blob/master/concepts/0289-toip-stack/README.md



@Sarah - to be clear, the link I provided was to the first diagram Rouven showed (the ToIP stack). I don’t have a link to this one Rouven is showing, but hopefully he does



The link is there but doesn’t have public access.
 
http://www.whimsical.com/U2YsBVLyBKgPt2rt76TFYs


Trust over ip: http://github.com/hyperledger/aries-rfcs/tree/master/concepts/0289-toip-stack


From Juan Caballero to Everyone: (11:19 AM)



+1 Anil. Proving control over a DID does not itself constitute what we typically associate with "authentication"



As an application or system software developer, I find this kind of diagram very helpful
Also, as a protocol implementer



^ Good feedback!



Also, as a community organizer.



@Sarah Me too, but then, I’m biased after a year of working on the ToIP stack
BTW, I’m still on the queue to talk about where storage belongs



Phrased in another way, this three layer stack would be: - Secure Data - Secure Connections - Public Key Registries


From Sarah Allen to Everyone: 
Aren’t we humans?


From Sam Curren to Everyone: 
speak for yourself Sarah! :)


From Drummond Reed to Everyone: What Anil is explaining is why we now present the Trust over IP stack with the ToIP Governance Stack on the left and the ToIP Technology Stack on the right. Because the needs of a trust community first have to be mapped into their governance policies, and THEN into technology


From Nader Helmy to Everyone: 
Credential handler API
 constitutes the basis of a secure connection the same way DIDComm does, but I would not classify it as "DID Communication"


From Drummond Reed to Everyone: KERI is actually completely at Layer Two


From Sam Curren to Everyone: 
Uh... maybe.


From Nader Helmy to Everyone: 
KERI is a DKMI. Seems like Layer 1.


From Juan Caballero to Everyone: KERI is a way of life
I like this one
still no idea where KERI goes


From Drummond Reed to Everyone: (11:45 AM) 
Yes, I would agree with what Rouven is saying. KERI is key management architecture.


From Brent Zundel to Everyone: (11:47 AM) 
You may not need storage for DIDcomm, but you would need key management, right?


From Juan Caballero to Everyone: (11:48 AM) 
should we call it... Secure Data Storage?


From Brent Zundel to Everyone: (11:48 AM) 
right, just trying to tease out the difference between storage and key management.


From Juan Caballero to Everyone: (11:48 AM) 
I, for one, would like a zany neologism like Vaulting


From Drummond Reed to Everyone: (11:48 AM) 
Yeah, I like that, catch term! ;-)


From Me to Everyone: (11:50 AM) 
it can potentially SOLVE a huge Relying party problem.


From Oliver Terbu to Everyone: (11:51 AM) 
Isn’t it a CCG work item or WG group?


From Brent Zundel to Everyone: (11:52 AM) 
http://www.w3.org/community/veres-one/


From Juan Caballero to Everyone: (11:52 AM) DID:sov ?
Oh that reminds me where is DID:peer governed?


From Sam Curren to Everyone: (11:54 AM) 
in a repo. :)


From Nader Helmy to Everyone: (11:55 AM) 
DID Peer is also in the process of moving to DIF if I remember correctly


From Sam Curren to Everyone: (11:55 AM) 
I believe that's true.


From Bruce Conrad to Everyone: (11:55 AM) In the sense that everyone who uses peer DIDs governs themselves? using code in a repo


From Juan Caballero to Everyone: (11:56 AM) 
it just struck me as a little cog with big consequences for the stack!


From Sam Curren to Everyone: (11:56 AM) 
governance is light for did:peer. it mostly relates to the governance of the spec itself, not really usage.


From Drummond Reed to Everyone: (11:56 AM) 
In the Sovrin Update session coming next, we’ll be talking about how governance frameworks fit into the Trust over IP stack


From Juan Caballero to Everyone: (11:56 AM) 
touché


From Bart Suichies to Everyone: (11:57 AM) 
I like the distinction between governance on the tech, and governance on the usage of the tech


From Drummond Reed to Everyone: (11:57 AM) @Sam Curren - exactly right wrt the did:peer spec. The governance there is entirely over the spec.
@Bart +1


From Nader Helmy to Everyone: (11:57 AM) 
We should accept it will be exceedingly difficult to get additional governance on chains like Bitcoin


From Drummond Reed to Everyone: (11:57 AM) 
+1


From Bart Suichies to Everyone: (11:58 AM) you cannot compare governance from tech, and legal governance.. they are separate.. need to exist both.


From Nader Helmy to Everyone: (11:58 AM) Governance is required at some layers, but not all and not in all circumstances


From Drummond Reed to Everyone: (11:58 AM) 
There can be different governance frameworks (including NO formal governance framework at all) at all four layers


From Juan Caballero to Everyone: (11:58 AM) 
and the other way around


From Drummond Reed to Everyone: (11:58 AM) 
Bitcoin has no formal governance framework at Layer One
Yes


From Oliver Terbu to Everyone: (11:59 AM) 
Ethereum can be permissioned as well


From Sam Curren to Everyone: (12:00 PM) 
Ethereum or ethereum ? (capitalization matters in this case)


From Bart Suichies to Everyone: (12:00 PM) is the question what layer's governance model should be leading? Tech driving governance, or the other way around?


From Juan Caballero to Everyone: (12:01 PM) 
^ I'm really not sure what the question is


From Juan Caballero to Everyone: (12:01 PM) 
it might be helpful for someone to state it


From Bart Suichies to Everyone: (12:01 PM) 
eg: governance model of layer 4 drives decisions on technology (how things can work, assurances on technology, etc)
or: bitcoin as a technology exists, and governance on layer 4 is based on top of potential of technology


From Drummond Reed to Everyone: (12:02 PM) 
+1 Bart


From Juan Caballero to Everyone: (12:05 PM) 
heyo we got 10 minutes left, did Rouven have questions?

From Geovane Fedrecheski to Everyone: (12:07 PM) 
do we have public examples of governance frameworks, with all (or most) of the roles fulfilled?


From Drummond Reed to Everyone: (12:09 PM) 
@Geovane - there are some at certain levels, but not at all levels yet. For an example of Layer One, see https://sovrin.org/governance-framework/


From Geovane Fedrecheski to Everyone: (12:09 PM) 
cool, thanks @Drummond!


From Manu Sporny to Everyone: (12:10 PM) 
Squirrel!!!


From Oliver Terbu to Everyone: (12:10 PM) 
Alastria


From Drummond Reed to Everyone: (12:10 PM) 
There are a lot of opinions about Layer Two, but if we are going to see the full benefits of a thin-waist protocol stack, we need ONE protocol on layer 2


From Karyl Fowler to Everyone: (12:10 PM) 
There you are @manu! we learned about Veres One’s community group earlier!


From Brent Zundel to Everyone: (12:10 PM) 
I think this has been a really good conversation. There are 5 minutes left. Where do we go from here? What are some concrete next steps?


From Oliver Terbu to Everyone: (12:10 PM) 
Alastria has defined a Trust Framework


From Juan Caballero to Everyone: (12:11 PM) 
^ ¡Viva España!


From JC Ebersbach to Everyone: (12:12 PM) 
@Oliver, do you have a link to the framework?


From Juan Caballero to Everyone: (12:12 PM) 
http://alastria.io/en/estructura-de-alastria/