Self Sovereign Identity Container
Self Sovereign Identity Container
Tuesday 1A
Convener: Sam & Adrian
Notes-taker(s): Maryann Hondo, Dan Finley
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Overview:
Sam---- idea behind decentralized identifiers ( see spec) DID –rebooting web of trust ( seeded ---- https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/did-spec-wd03.md)
DID--String that can identify a record on a blockchain
What should be in an identity container?
An Identity Container Contains:
1. public key to show proof -- this shows I have control of the DID
2. Service pointers ---anchored to the chain but not in the chain
3. Attributes (issues for correlation)
- a. Self asserted
- b. Verifiable
Follow the service pointer to get to an identity container ( agent, hub are terms that are also sometimes used )
how do you manage tokens that control resources ? How to do this in a self sovereign way ---
UMA concerns itself with issuance of access tokens ---Background --- Self Sovereign (UMA for healthcare background)
[Audience discussion]
DID ----Identity that I own --- Confusion on the scope of the web….. Lots of discussion on what is “verifiable” In effect FIDO can address this problem
Is this a discovery mechanism? Format of the identity container is what is in scope.
This is a self sovereign identifier not an “identity”.
- • An identifier that you own and use to establish permanent connections --- no one else can revoke your identifier
- • Definition of self sovereign – no privacy policy needed ---- you have it under your control
This Session focus is on claim (other aspects will be discussed in other groups today):
On chain (DID) and Off chain ( self sovereign identity container)
Identity container can contain an authorization service link --- this service could then ( under policy from UMA) gain access to the specific resource
What is the “container”? only data? With restful api? Some look like api’s (standard in interface that is implemented in different software)
Some suggestions:
- • Policies/private keys
- • Machine learning
- • Authz server
- • Secure elements
- • Public attributes
Other definitions for the “identity container” scope -----
Hub --- data only Agent --- code/data
Binding process of using verifiable keys is part of the yet undefined trust ---- what the relying parties require is another aspect of the problem space
An example:
- • Licensed practitioner is a self signed entity
- • Patient is a self signed entity
- • 3rd party would be enabled to accept the self signed trust
Another way to look at it …..re-orienting the federation problem to bootstrap an alternative trust model for user centricity
If this binds the user, how can you change the record if something changes?
- • Typically the chain ( that is the anchor) has a mechanism to accept a new version of the record ---
- • The default resolution returns the most recent record --- since “most” chains are write permissioned --- open read--- you can authenticate the chain of records …
Suggestion from the audience ----there is previous work to be leveraged---Bacnet/Zigby application profiles
Goal is to elevate people to be first level in API use
BYU is doing domain of one’s own. When they graduate it is something you take with you.
In the EU they have GDPR and PFD2 See Phil’s session on Self Signed
Additional notes by Dan Finlay
All quotations below are general summaries.
An identity container has a series of attributes, added permanently as part of the blockchain. You can own many identity containers. Resource servers publish claims in support of a container’s attributes. By creating new containers freely, you can resist correlation, albeit not fully prevent it.
It may be less confusing to call it a self-sovereign identifier, instead of identity. What you really control is a container with a unique ID that you have personal control over (at least as well as you can manage its permitted keys). Identity may be a more abstract concept, that is not as technically tangible.
Adrian’s definition of self-sovereign: Something you do not have a privacy policy with. No institution, no CA that certifies you are this thing, it is only your own personal claim.
Since the identity container is on-chain, you should generally only publish attributes to it that you are not concerned about disclosure in the case of key compromise. Blockchains primarily solve the double-spend problem, so the only thing you definitely need to record on chain are things that need to be tracked over time versus double spend.
DISTINCTION:
Self-sovereign identifier DID lives on chain, and has a public key service pointer.
- This container defines the schema of the identity container.
Identity Container knows attributes that are not recorded on chain. Also known as an agent or hub.
- Policies & private keys: Things that never need to be shared.
- Authorization Server: Personal code & servers that the user runs.
- Machine Learning
- Secure Elements
- Public Attributes: Things you want to broadcast, things that require no auth, identity claims that you want to make public.
- Public APIs: Services for interacting with other containers & sites, big open space.
An external service requests the container to prove something, which can then provide a claim from a 3rd party. The external service can then verify with the 3rd party for further proofs.
In the UMA model, you ask for a pointer to an authorization service from the container. In some cases, you might trust the container with its own claims (trusting your friends to report their allergies before your dinner party, for example).
If the DMV offers an auth API:
W3C Verifiable claims
If someone asks me for my driver’s license, your container returns a DMV-signed claim of your license.
Sam says: Application Profiles has 20 years of established work doing this same stuff for connecting networks of sensors and actuators. This is all an interoperability and federation problem. BAC Device Profiles: http://www.bacnetwiki.com/wiki/index.php?title=Device_Profiles Zigbee Application Profiles: http://www.eetimes.com/document.asp?doc_id=1278223
Examples:
BYU “Domain of One’s Own”: https://byuoit.atlassian.net/wiki/display/DOO/BYU+Domains+Home
Doc: GDPR’s enforcement looming is opening companies up to “pushing liability to the edges” in ways they’ve never been before.
