The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2018-06-05

Dave Longley is scribing.
Kim Hamilton Duffy: If there are any other DID focal use cases when we get to it please add yourself to the queue.

Topic: Introductions

Kim Hamilton Duffy: Anyone new that wants to introduce themselves?
Ryan Grant: My name is Ryan Grant, I came to decentralized identity through bitcoin connections and I'm mostly working on the BTCR specification (a DID method). Digital Contract design has some code coming together at the link I just posted in IRC. I'm happy to be part of this group.

Topic: Announcements and Reminders

Kim Hamilton Duffy: We had talked about a summer DID credentials outreach. For both of the reminders there are issues we'll talk about in the next section. Let me just jump through them real fast and then we'll get to details.
Kim Hamilton Duffy: The MyData conf in Helsinki is happening, issues to discuss about that.

Topic: Progress on current action items

Kim Hamilton Duffy: For the summer outreach DID credential hackathon. We had talked about having it the week of July 16th but there are things happening at the same time. We we're sure if we should have it then or pair it with something else. Microsoft, I think was also planning a hackathon. It wasn't clear if there were enough people around.
Kim Hamilton Duffy: Joe do you have any more context on that?
Joe Andrieu: We had to do an outreach hackathon not so much for the implementers but for those who want to figure out how DIDs work and get hands dirty for the first time. MS said we'd like to sponsor something later in the summer but also some of the DID methods aren't quite ready yet so better have the summer. Sponsored by MS or coordinated, co-located with other things, etc. would be better perhaps.
Kim Hamilton Duffy: Just a heads up for now -- that will likely be moved or clustered with something else.
Joe Andrieu: Sorry, Dan. I've got new networking hardware en route. My audio needs help. =(
Kim Hamilton Duffy: I will need Joe or Christopher again here -- the MyData conf in Helsinki, there was some discussion about a DID panel but we've heard from the organizer that won't happen but instead we're having a few specific talks about DIDs. We had also pondered the idea of having a separate event afterwards.
Kim Hamilton Duffy: A day focused on DIDs the day immediately after. There was some organizing we'd have to do there. Kaliya mentioned there's a breakout session on Wednesday -- perhaps coordinate with her during the conf to get interest in the side event. We will get you more information, add yourself to the queue if you want more information about that.
ACTION: Kim check with Kaliya regarding breakout session at MyData
ACTION: chairs remove salon from action items
Joe Andrieu: At IIW, Christopher Allen and I spoke with the organizer at MyData about doing a Rebooting Web of Trust salon around the same time. Finding a venue and dealing with logistics ... we opted not to do that on Saturday. We had considered it, it won't happen. There will be a lot of content and we will help promote. Folks from our community will be on panels.

Topic: Status of Work Items

Kim Hamilton Duffy: I was told to call on Manu for DID WG.
Regrets+ Manu_Sporny
Joe Andrieu: Manu mentioned he was pretty happy with how things are advancing things for a DID WG. I'm thrilled with all the Use Cases coming in.
Joe Andrieu: It's an ongoing process but that's one of several deliverables, we have the charter, we have DID methods that need to get into place. Conversations with the rest of W3C and Manu expressed he was feeling good about that but since he's not here that's my report.
Kim Hamilton Duffy: Thanks, Joe.
Kim Hamilton Duffy: Any volunteers to give status updates on work items?
Ryan Grant: This is a DID method status report. I posted the link for our code earlier that we're writing in C++. Posted again.
Ryan Grant: If anybody is interested or capable at taking this stuff or has any comments about how they want to plug it into other layers like a method resolver, please give us some feedback. Thank you.
Kim Hamilton Duffy: Could you talk briefly to the extensions? TXREF encoding, etc.? It's not accepted but used pretty widely. BTCR wants to use it but we also want some extensions to it to include, for example, output index, things like that. Dan has been working on a draft to extend that proposal, do we need any support on that? What are next steps?
Ryan Grant: Next steps are that we improve the existing BIP (a proposed one, not accepted yet).
Ryan Grant: We need to improve our explanation for how to parse the difference between a reference to a transaction and this thing we're doing that will reference directly into a transaction output of a transaction.
Ryan Grant: For those who understand blockchain stuff -- each transaction can have multiple outputs and we'll extend the existing idea for that a little bit.

Topic: Focal Use Cases for DID WG

Bohdan Andriyiv: Last we talked a little bit about this use case. The idea of the use case is to globally uniquely represent human individuals using statements. We want to represent human people in the real physical world. And we want to do this in a unique way.
Bohdan Andriyiv: One human person should have only one unique identity. Why do we want to do this? We want to create documents that are called [?] that we can use to maintain ValidBooks services.
Kim Hamilton Duffy: This is use case #9
Bohdan Andriyiv: ValidBook services are meant to improve corporations, governments, do intelligent things. To put into practical perspective, we have social networking services and it is well known that they are not optimized for interests of their users but informed by the interests of the companies that are behind them.
Bohdan Andriyiv: The original idea was to create social network services that aligned with the interests of their users.
Bohdan Andriyiv: In order to do this we can use DIDs and create self-sovereign identities and these identities can create statements of unique representation of living human individuals and called [?] statement.
Bohdan Andriyiv: Any person can have any number of digital identities. But one digital identities makes new verifiable credentials that represent a unique human individual. That identity provides proofs for that statement and asks communities to endorse that statement.
Bohdan Andriyiv: After that we have other identities that have higher reputation they can estimate those proofs and endorsements from the community and we call them arbiters. They can acknowledge and say this ?-key claim is valid. That identity can receive kudos.
Bohdan Andriyiv: In this way we can create tokens, money that is value, to maintain and provide services.
Bohdan Andriyiv: Does this make sense?
Joe Andrieu: Thanks, Bohdan. That's a very interesting use case. How are you addressing deduplication -- you mentioned uniquely identifying a single human person.
Bohdan Andriyiv: The defense against single attacks, so for example one human person can create a lot of claims. A lot of identities and claim they represent different real living humans. The key question to possibility of unique representation of living humans, I think it is possible through the use of arbitration service so there is a link that describes how arbitration service is going to work. A demo/alpha version of the arbitration service is available too.
The burden of proof is on identity.
Bohdan Andriyiv: It must unique proof it uniquely represents a living human. It could use Verifiable Credentials with evidences that it owns or controls social networking services for example, facebook, twitter, etc. accounts of these services. When an arbiter looks at this proof this is some proof that this identity represents an active real human.
Bohdan Andriyiv: It can be typed in different ways so the best to prove an identity is real and unique is to have endorsements from the community.
How do you prevent an organization "gaming the system"?
John Jordan: So ... this valid book idea is effectively trying to implement a global trust framework around the concept of a relationship graph
Bohdan Andriyiv: These endorsements are represented on the arbitration service on the endorsers graph and arbiters can see who endorsed the claims and who endorsed those endorsers and so on.
Bohdan Andriyiv: Arbiters will be able to see a short graph between identity... for example, there is an identity that claims to represent a student at a university. It provides proves it owns a LinkedIn account and in this proof we can see that this person is a student at some university. It is logical that that student will have in the endorser some facts from for example the president of that university.
Bohdan Andriyiv: Arbiter can look to see if there are some professors or the president of that university who are endorsers on the graph for that identity.
Bohdan Andriyiv: In practice, it should be quite reliable. To find honest identities.
Joe Andrieu: Ok, great, thank you.
Adrian Gropper: Two quick points about this. First -- I did speak with the chief architect of ? -- they have to apply these identities in the real world in healthcare, etc. You don't necessarily want to deduplicate people whereas in finance you want to do that. I don't think we as a group have come to grips with this duality as we relate to DID. The second point is that I don't understand this arbiters. Are they different federated identity?
Adrian Gropper: Could you pick Facebook or something? And have them do the deduplication? How is it different?
Adrian Gropper: One of the things we find essential with the work we're doing with DID is that we don't need to involved federated identity providers like we used to. I'm a little confused about reintroducing that idea and what that means.
Bohdan Andriyiv: The arbiters estimate the validity of claims. Arbiter means to say whether identity represents a living human individual. They don't need to understand the real name of that person or any other kind of information.
Ryan Grant: The DID-spec allows Federated systems to use DIDs to interoperate with fully decentralized solutions.
Bohdan Andriyiv: They don't need to know what they look like, just estimate the validity of the claim.
Bohdan Andriyiv: The main use case is to create tokens to finance the operations of ValidBook. Now we know that we can create tokens because we have blockchain. There is of course Bitcoin, but the problem of Bitcoin but it can't be used to finance corporations needs to be fiat. We have precise estimates for the number of people we will have over time -- so let's create one token per person today. So 7.5 billion tokens per day. So now we want to distribute them. We
Will distribute tokens only to identities that have been verified ... so they have a strong incentive for people to provide proofs that their digital identity is valid.
How do you punish people making false "certifications"
Bohdan Andriyiv: But who will estimate those proofs? Arbiters. Who are the judges. If we are going to have a central authority it's corruptible. So we want decentralized arbiters. Any identity can be an arbiter. Some identities can be pseudonymous and not linked to a person and this identity accrues reputation and becomes know to provide good estimates for claims.
Bohdan Andriyiv: So people can analyze if the "SURLHI" claims are valid or not.
Adrian Gropper: I can't follow this process, let's keep going.
There is also a problem is "knowing who your friends are" - isn't that what facebook is in trouble with now?
Ryan Grant: SURLHIs are welcome to use DID protocols of course, but I'm seeing a conflict with revealing the narrowist information for some purpose. If I reveal a SURLHI to a website it seems like they can correlate everything. Which is against the spirit of creating separate DIDs for separate purposes.
Raise hand
Bohdan Andriyiv: You can still use separate DIDs for different services but if you want to create an identity that uniquely represents you you can do this. This arbitration service will estimate the claim that it uniquely represents you and it depends on the level of rigor you want to have.
Kim Hamilton Duffy: I'll freeze the q for this topic after dcc; next we'll move to Yancy's use case
Bohdan Andriyiv: The idea is that we want to create value for these tokens. It is also very important to distribute them in a fair way. If we look at Bitcoin, question about government, another about fairness. It mostly belongs to 100 entities or something like that. Now the rest of the world doesn't have access to them. The idea that they can be distributed with time. The idea here is that we can not only distribute token in a more fair way but also use them for
Something useful. To create and support corporate services.
Bohdan Andriyiv: Social networks, it's evident that they are not good now, do not preserve privacy, etc. The same with other services, emails, no strong incentives for these providers of these services to make them end to end encrypted because they use data for advertisements. These services need alternative funding. There is also a need for standards like Verifiable Credentials so services can accept something standard.
Joe Andrieu: To Adrian's point -- are these arbiters introducing centralization? We could think of them as notaries. They've looked at your documentation and the person who is signing has the ID card or whatever. That architecture means you are getting a body to evaluate claims and make endorsements of claims.
Dcc: It seems to me that by having this graph you basically have a network of people you know where these arbiters can find out all kinds of information about you by with whom you associate. Facebook got into trouble with exactly this.
Bohdan Andriyiv: If you don't want the public to know you won't play this SURLHI game. You won't add that person into your endorsers graph. It is quite public information with whom they are associated. Another thing is that it was dangerous with Facebook, Cambridge Analytical also knew not just who those friends were but what they liked and so on.
Bohdan Andriyiv: Here that information can be closed, so it's ok.
Can you control who endorses you?
Bohdan Andriyiv: It will be public with whom you are associated but it won't be public what those people like.
Bohdan Andriyiv: You can control who endorses you, they can endorse you back.
Samantha Mathews Chase: Why would you have people verifying people's identity if you have two things like Facebook and Google -- something like your location data from those two silos would identify you. Why do you have to involve other people?
Samantha Mathews Chase: If you have data from two different places why can't those be credentials if they line up to tell the same story?
Bohdan Andriyiv: Can i create more than one SURLHI, and use different SURLHIs at different sites? If I can, then i can use multiple DIDs, and I won't be worried about this. [scribe assist by Ryan Grant]
Joe Andrieu: Nice, dlongley
Kim Hamilton Duffy: Any follow up on Samantha's last point?
Joe Andrieu: I could download all my data from Google and provide that to someone else -- I wouldn't do that.
Samantha Mathews Chase: I'm talking about Kaliya's personal cloud. It's your data. If you have two separate points, say your location data on your phone and the location data of something else that could prove you are in the same place.
Joe Andrieu: The trick is how to leverage that data without revealing it.
Samantha Mathews Chase: So you need a personal cloud to do that.
Samantha Mathews Chase: Could you have an ID that is a streaming access to your data? Why are we asking for privacy when we don't have it any more?
Adrian Gropper: The arbiter doesn't solve the deduplication problem.
I think your use case fails when an organization works against it.
Yancy_: A basic use case for DID -- essentially it would just be a way for people who use social media to request reputation thresholds. I'm sure people have seen spam detection on social media. The idea is a reputation system that could be linked to on any social media account.
They hire multiple people that then endorse one another, and get a few real people to endorse them.
After establishing themselves (which may take a while), they then overwhelm a reputation based service.
Yancy_: Each social media provider wouldn't need to create their own banned lists and fight spammers on an individual basis but by using a decentralized platform we can around the problem of having one authority in charge.
I believe this is already happening today.
Yancy_: Full authority over everybody's reputation. Obviously there's a lot of details to figure out as far as implementation and one of the other things this algorithm could define is how you could calculate reputation. Maybe even bots could have DIDs that they could use to interact on social media.
Moses Ma: I think Yancy's idea is valuable and deserves more brainstorming.
Yancy_: There should be a way to identify that bot activity.
Yancy_: I think that's a summary of what I had in mind.
Yancy_: The descriptions on the Google doc I shared.
Bohdan Andriyiv: Q
Kimhd -- yes.
Adrian Gropper: Two questions. 1. Are you not describing another instance of the dedup problem? I think the last thing you said in terms of the bot acting or creating bots as a form of sybil attack, it sounds like a variant of dedup issues from the previous use case. 2. Every time I've talked to people and I'm very interested in the reputation problem and using DIDs.
Adrian Gropper: Everyone keeps coming back and saying reputations have to be contextual. If we want to tackle a reputation use case which I would encourage you or us to do, there would have to be someway that we account for context. Or that we agree what the role of context is relative to reputation.
Yancy_: Yes, your point about dedup, yes, I think there's overlap. This is sort of something that goes along with some of the other problems for example, someone with a DID or a spammer upvotes with another spam account how do you address that?
Joe Andrieu: +1 Reputation, like trust, is not a blanket. it is highly dependent on what the reputation is for
Yancy_: It would be an open problem that would need to be solved. Wrt to contextual reputation, I'm not 100% sure what you mean by that. Could you give a quick example?
Ryan Grant: Context: Facebook versus Linkedin
Adrian Gropper: Having the reputation of my Lyft driver is very different from their credit score reputation. If I'm a bank I don't care about his driving record and if I'm a passenger I don't care about the credit score.
Kim Hamilton Duffy: We're getting close to time; i'll freeze the queue at Bohdan
Or you care different amounts!
Yancy_: A driving score can give you a reputation that you're not a bot. So in some sense I do agree with that.
Ryan Grant: Does use of this system -- start one with an initial score that is higher than a bot if so, why? Why can't a bot just do that?
Joe Andrieu: To quote from the case: "Build a reputation system/algorithm where a newly acquired DID always has the lowest reputation, and then over time and with favorable actions, that DID can build a reputation. "
^Looks like it isn't the case
Kim Hamilton Duffy: My reading is that everyone starts at the same level and you have to increase your reputation.
Yancy_: Yes.
Bohdan Andriyiv: Wrt to dedup, in the context of ValidBook, it's not that we need to know for sure if this identity has no dups, rather some percentage we can allow to have fakes. It's inevitable. It's not the same as going to a physical notary that checks your passport. With time SURLHI claim will be as valid a physical government issued document. Regarding contextual reputation, arbiters reputation is only as good as their rating of SURLHI claims.
Bohdan Andriyiv: And SURLHI is just a reputation that it's a real human.
Ryan Grant: Thanks Bohdan.
Joe Andrieu: Thanks for the discussion and for the multiple people that have taken time to do a write up in the format requested. Moses and Adrian we'll get you in the discussion. We'll push them through a process that will refine them and pull them together into a coherent single document. Great starting point and thank you for the contributions.