Convener: Phil Windley
Notes-taker(s): Susan David Carevic
Tags for the session - technology discussed/ideas considered: Sovrin Ecosystem, Verifiable Claims
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Bank issues Alice a verifiable claim.
Alice shares a proof of her address with ATT based on verifiable claim
ATT and Bank do not need business relationship.
In the system, the Bank, Alice and ATT are Decentralized Identifiers (DIDs)
Verifiable claim contains information about who the bank is and who Alice is.
Identifiers are important to be able to track the proof to the right source
ATT needs to know something about the bank – they need to know a public identifier for the bank. ATT knows the Banks DID for these types of credentials
Why does the bank need to issue the verifiable claim to Alice in the first place? If you are the bank, you have KYC data for Alice, why would they share it? Another bank could freeload off of that information.
- - There is a bi-directional aspect to this work – if you are creating them, you want to accept them as well.
- - ATT will want to know that there was a bank relationship.
- - The arrows could go in the other direction as well. ATT’s verifiable claim for Alice could be useful to the bank as well
Converted network effect to two sided network that can scale – typing point will be reached where two sided network will receive more value from single sided.
Rabbit hole discussion:
Know your customer (KYC) processes are very expensive – if the costs go down for this, entities will engage in more business.
In terms of an organization, how do you delegrate authority over an organization’s agent? Delegation for Agents: Need to make sure that the agent can’t impersonate you. Agent gives proof of credential and proof of authorization to provide it. Recipient needs to decide if that is good enough.
Mary (at the bank): acted fraudulently – bank needs to be able to revoke proof retroactively.
User can have two bank accounts and two accounts with ATT – User decides whether or not to correlate them.
Verifiable claims based on information contained in the ledger. Identifier for the claim definition for the schema in question (not using tech stack of certificates).
Back to discussion.. rabbit hole tabled:
ATT can only unlock proof if they pay for it. Bank ultimately get’s paid for proof. Trying to create a system without correlation. Payment mechanism needs to be built into the lock. This is why we are exploring a token for Sovrin – so that we can have verifiable claims that are paid for by the identity owner, or the business needing the claim. (real world examples: transcripts)
Question from earlier session: ATT relies on the bank for my address, and they screwed it up. Maybe Alice put in a false address intentionally. Token could be used for insurance.
Privacy preserving value transfer is an important part of making system work. People will want to receive payment for providing a verifiable claim.
In order for the sovrin ecosystem to be an economy, any of the actors could be receiving and giving payment at the same time. Everyone should have an opportunity to participate in the economy. You don’t want all of the tokens ending up with the same parties, and not getting dispersed.
Working with Imperial School of Economics to look at the “Tokenomics” of all of this.
ATT get’s to choose what type of credentials they will accept. Business would have to decide what types of proofs they are willing to accept.
Is consideration being put in place so that people who can’t afford services are not priced out of this service? Sovrin has an “Identity for All” counsel. They will delegate tokens for this purpose. Sovrin is sensitive to the idea of a tax, or denial of service due to not being able to pay.
For Etherium or Bitcoin there are built in transaction costs. What is the difference between this and sovrin:
Writing to the network looks free: we haven’t put in a built-in transaction fee. Sovrin is on a public\permissioned network.
What is the advantage for a company to do KYC this way? For companies that don’t have this, this might be easier. There are a lot of business bases where the integration for verification is too costly. This is also about giving another market for the data.
Premium claims: have a price tag on them.
Managing stewards on ledger
Agents: If I’m a person who wants to use Sovrin, I use an agent to store my information. And I need a connector to manage my keys and tell my agent what to do. The architecture for this is not dictated.
Agents are specified and certified by Sovrin Foundation, but they are run by outside companies and we call them Agencies. (similar to browsers) Agencies are private companies that build somewhere and run services for people.
Apps: Applications of Sovrin. Most work through Agents and use these to interact with Sovrin.
What is your vision for the token: Great set up papers “Community Token Economies” envisions large community with players on top of stack that might have their own tokens and economies. It requires interoperability and we are building this into the Sovrin Token.
Are there other options for structuring incentives? Sovereignty is a border – not 100% control. Alice has control over some things. Alice decides what claims she takes and what she sends over. In the physical world, you don’t get to decide all the things people say to you. She can choose what she should share. It is possible for incentives to be structured, where Alice get’s paid for her claims.
Another example: location claim as a transaction is taking place, so that the bank has additional information to prove who the customer is.
Alice wants to protect her money at Bank A – she might want to validate her location at the Bank and not receive it from ATT – are we excluding Alice from the system? No – just from the example.
The business process is up to people, not Sovrin – Sovrin is just an Ecosystem that supports the process.