2E/ Decentralized Semantics 101
Decentralized Semantics 101
Tuesday 2E
Convener: Paul Knowles (paul.knowles@humancolossus.org)
Notes-taker(s): Neil Thomson
Tags for the session - technology discussed/ideas considered:
Data, Semantics, Schema, Input, Data Capture
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
The form of the session was a presentation (intended for those new to the subject), followed by Q/A and discussion
Presentation: Decentralized Semantics 101
Vocabulary:
Form - taken from paper forms used filled in by subjects and service provider reps (e.g., clinician). A Form is a composite/aggregate packaging of claims/attributes from one or more Verifiable Credentials (VCs) for presentation (e.g., to a verifier) or for data exchange.
Q/A & Discussion
[Erica Connell] If a DID has a DID Doc, how does a VC exist with relation to a DID?
A Credential is something you would put in your wallet. Using a vaccination (status) VC as an example, what you put in your wallet is an equivalent of a paper vaccination card with your identifier (of some kind, binding the card to you) and a date completed. All the supporting data (including PII data, details on the lab, vaccination batch, etc. etc. ) may be in separate VCs (which the vaccination status VC is derived from), such as detailed information on the vaccination visit.
A DID is NOT the identity of the holder, it is a communication channel identifier for enabling holder to service agency communication. A DID may be created for each communication channel (e.g., one for each internet service) or for each transaction.
A subject/holder’s identity is defined by their VCs, which are obtained from an Issuer by creating a communication channel where the Issuer and Holder each present a DID for the channel, verify identity and trust by exchanging existing VCs (with minimal disclosure), followed by the Issuer creating and delivering a new VC, based on data (lab vaccination data/credentials) held or provided to the Issuer (e.g., it’s issued by the lab that did the vaccination).
[Steve Venema] - How does the Dec. Sem. model work with the lifecycle of a VC (e.g., specifically revocation)?
Scenario - your vaccination VC is revoked (rendered invalid) by a later discovery that the vaccine was not effective, or the vaccination batch was compromised.
Revoke in this case may be marking the VC as being invalidated (note: should be a standard field for any VC, including a reason for the invalidation). There is still value of the invalidated vaccination VC (and underlying health record data), so “revoke” is not = discard the VC (and underlying data)
A key layer (top layer in the Trust over IP model is governance. And governance is determined by jurisdiction (e.g., national, province/state, agency, ….), which is where complications due to different criteria, processes and approval complicates interoperability .
[Erica Connell] What is decentralized about this approach?
While the creation of the data collected for a vaccination and how a vaccination status VC is constructed and bound to the user is defined by a governance authority (central), the key is that while a [VC] Issuer will keep a copy of the issued VC, the holder (person) for whom the VC was issued is the one that stored and controls access to their VCs and health card records.
This is analogous to a paper travel passport. The Gov’t may have a record of issuing it, but only you - the person in possession of the passport - determines where it is stored and where it is presented.
How decentralization applies to the Input/Semantic model
Decentralized identity - authentic data
Decentralized semantics – harmonized data
Decentralized governance - distributed data
Root of trust – KERI vs. ledger (semi centralized)
KERI allows on personal device
A concern is that the current (many) DID methods which are typically tied to blockchains or similar ledgers become a lock-in a “root of trust”. For example, if you have Europe and China using different DID methods tied to a different ledger (blockchain), then they will not share a root of trust, which makes interoperability difficult.
The KERI model allows for decentralized root of trust based on DIDs and other structures under control of PIK management controlled by the holder.
How does a holder/subject delegation (guardianship) work in this model (parent/child)?
Guardianship can go very wrong in a “crooked family”.
This is a complex topic covered in some other sessions (sovrin presentation by Jo Spencer at IIW 32). Two experts to connect with are Chris Buchannan (Mitre) and Jeff Orgel (Jeff O) who are both attending IIW 32.
[Lucy Yang] A key factor for delegation/guardianship is the governance framework (which is a key part of Trust over IP)
[Jeff O] A key issue on identity, guardianship and governance is that the human (operating system) needs a clear and understandable (but not necessarily simple) model of the roles, rights, responsibilities and interplay in a guardianship relationship - of the guardian and the dependent.
The digital (identity) operating system needs to support the human model, to the vice versa.
Governance in this case is derived from “Policy” and logically sound policies (on paper) don’t necessarily map to real life/scenarios or how people think about the subject matter covered by policies.
To be continued in other IIW 32 sessions...
