Manu Sporny: Thank you joining us, Christopher. We're really looking forward to getting your input on this VCTF work. ✪

Manu Sporny: Just to be clear we are minuting the call and recording the audio. ✪

Christopher Allen: You have my permission. ✪

Manu Sporny: Let's start with a quick introduction -- we'll be sharing this with multiple groups at W3C. Background and self, etc. ✪

Christopher Allen: I've been involved with online communities since the early 80's. I was one CompuServe, head of the computer international consulting association ... consulting board on there, I had hosted a number of BBSes, I published the first BBS for the Mac and the first Mac interface for a online community. ✪

Christopher Allen: I was also involved with early pre-internet methodology for transmitting information including [missed] which is like news today but it's a p2p protocol. So we can talk about how we did that back in the 80s, it's not new. In the late 80s I was involved in [missed] involving the technological consensus with database architectures and such and the human problem and the core of what I wanted to work on for the next 25 years. I came out with my first product and people didn't trust it so I entered into crypto. I was involved groundfloor with RSA and its algorithm and involved in its privacy efforts and [variety of crypto tools] in the early 90s. That ultimately set the stage for writing the reference implementation for SSL and then later leading the standards effort for TLS 1.0 at the IETF. ✪

Christopher Allen: I was the editor along with Tim Dierks for the standard and ran the online communities, mailing list, for all practical purposes I was the defacto director of that working group and we published version 1.0 of the standard in '97 and today it's the most widely deployed security standard, [stats on business]. Early architecture decisions we made proved to be solid like perfect forward secrecy which was something that was in the spec early on, it's only been implemented in the last couple years. Not only used to secure the Web it's used to secure other standards ... the ports I registered for doing SSL email later TLS with email, Google reported last year 60% of all outgoing email was secured by TLS and 50% incoming. Which is in great excess of anything secured by SMIME or SFTP anything. ✪

Christopher Allen: In the last 10 years I've been an Angel investor, involved in various online communities, in particular in the mobile community. In the crypto field I did some work at Certicom and did smart signatures and smart contracts but it was too early, in the last few years I've been bringing those skills back to secure android platform and most recently I've been doing stuff in the blockchain with secure engines of trust in the last yera, including teaching in university and doing consulting for big and small. I've been working on OASIS standards to help XDI move to blockchain. ✪

Manu Sporny: Awesome, that was a fantastic intro to you and that's why we're so interested in hearing from you. We think you're uniquely qualified to talk to -- about this problem space, if it should be solved, how you'd solve it, etc. ✪

Manu Sporny: What we're trying to do during this call is get your thoughts about what we've written so far, user-centric vs. service-centric, is there a problem to be solved, where should the work be done, etc. ✪

Manu Sporny: http://w3c.github.io/vctf/#problem ✪

Manu Sporny: http://w3c.github.io/vctf/#design-approaches ✪

Manu Sporny: What we're trying to do is ... the main gist of the way we're stating the problem here is that we're talking about user-centric design. We're asserting there is no widely user-centric standard for expressing verifiable claims, via the Web and there's a desire to create such an ecosystem. We've tried to define was user-centric means through talking about what some of the design ramifications are. For example ... ✪

Manu Sporny: A service-centric system would be like facebook, twitter, etc. ✪

Christopher Allen: Right, I'm very familiar with this movement, as far as calling it user-centric was really pushed in the late 90s early 00s, augmenting the social network, the early thing ... I've been part of the IIW community pretty much from the beginning. The core of the ... problem, my alignment is with it being about user-centric. It's been co-opted a little bit, but I've been moving increasing into "self-sovereign" as the key-phrase for this. Which is a little distinct from user-centric. But clearly the same territory. I think ti's important for a variety of reason. There's an innate power imbalance in our society where individual power severely hampered by the financial power and the legal authority of other parties. Going back to the US constitution, how do you enable the individual to balance that power around authorities. ✪

Christopher Allen: The natural power of aggregation of financial authority, etc. we need forms of everything from the class action lawsuit, etc. to overcome these kinds of natural aggregation and network effects that happen in system.s ✪

Christopher Allen: We have to balance those natural powers with powers that are for the user. That's where the self-sovereign is a bit stronger and why I value that myself. Clearly, the world in the last few years has been going ... ✪

Christopher Allen: We moved to centralized structures and we had problems there and then out to decentralized and we had problems there and then back to centralized and we're in the middle of a centralized surge. Facebook, etc. Governmental powers wanting to do things. I'm not a libertarian, I don't consider myself a cryptoanarchist or anything, but I do believe in balance. ✪

Christopher Allen: That clearly is part of my motivation with being involved in these decentralized techs that are finally possible today. They haven't won. Banks, etc. are looking at this as something they need to investigate. At this point there is no proven example there. ✪

Christopher Allen: Walking through this, user-centric is the first thing that I do, I am also very ... I think the space of verifiable claims and attestations is a very important sweet spot. Interop is very powerful. We've talked about service-centric architectures mean that people who lose their facebook relationship for whatever reason lose years of identity and reputation and history with their peers. ✪

Christopher Allen: If you go by the individual definition of social network individuals own their own social network, it shouldn't be owned by a service. Lock in and fragility or the opposite of it like resilience is important. Standards that cut across industries, clearly, we have a lot of issues in the area... I'm a big fan of privacy I write a lot about it but if you look at a lot of things and how they are legislated like HIPAA, they enforce a man in the middle. Which is the antithesis of what cryptographers want to avoid but it's mandated by the legislation. That has to do with the centrality of things again. ✪

Christopher Allen: Maybe they'll come up a little later in this discussion, but I also want to look at things from a crypto perspective and in order to prevent things like correlation, to allow for certain kinds of privacy things mandated in the EU or .... you can't do some of these without designing from a self-sovereign perspective from the bottom. It *has* to be done that way from a crypto perspective, I can't see how you can do it the other way. You can have wonderful policies about how all of this can work what can be shared and you can enforce them by policy and then have things like "more Jews died in Holland in WWII as a percentage of population vs. Germany" because policy respected them but then things changed. So just because policy works today doesn't mean it won't fail in the future. Building things on human rights privacy is good but policy is based on economic rights sometimes. The European style rights privacy can't be solved by a service centric perspective, at least I don't know how to do it, it can only be solved from a user-centric perspective. 30+ years working in this community. ✪

Manu Sporny: Do you think we're in the right ballpark then ... with our assertions about user-centric systems. If we were to do one thing that would be creating this self-sovereign approach for verifiable claims would that be a worthwhile endeavor? ✪

Christopher Allen: Yes. The only thing missing seems to be policy and maybe more crypto. ✪

Manu Sporny: In way way do you feel it's missing? We point out this needs to involve crypto, it's not a policy based solution we're searching for it's a crypto-based solution? ✪

Christopher Allen: Yeah, and I dont' see that in the problem statement. ✪

Christopher Allen: Nothing talks about that enough. ✪

Manu Sporny: Ok, I think that's just fundamental assumption we're making but we should point out that that's how we intend to address some of that in the problem statement. We were asked not to propose solutions but to just identify the problem -- and let the solutions come out in the actual work later. ✪

Christopher Allen: You're not mentioning it at all and you will have to be diving into it. Even if you don't talk about it ... maybe they are more principles, a couple of principles are necessary to say, we've already talked about self-sovereign, but maybe add to that something along the lines of minimum-disclosure required to interact. Which might include methods like [missed]. We don't know .. it's a hard problem space, we want to encourage minimum exposure but we want to enable business interactions and cooperation. So what is the minimum necessary to do so and not go beyond it. Today it's all or none. ✪

Manu Sporny: We will try to work that in. Where should that go? ✪

Christopher Allen: Maybe as a "principles" type of thing. ✪

Manu Sporny: Any other concerns over the problem statmeent? ✪

Christopher Allen: Nope. ✪

Christopher Allen: Again another principle is the [missed] ✪

Manu Sporny: The area of correlation ✪

Christopher Allen: The area of correlation. ✪

Manu Sporny: So I feel like we've covered user vs. service centric design. User-centric being a better way to address the problem. ✪

Manu Sporny: That's a fair statement? ✪

Christopher Allen: Yes, there are things in user-centric design that make it harder for large orgs to do certain things but they have more money and power, and I consider that an acceptable balance. ✪

Manu Sporny: http://w3c.github.io/vctf/#benefits ✪

Christopher Allen: I can live with this, every time I hit "consumers" I understand you're trying to handle the naming here ... whenever I hit "consumers" I keep wishing it was another word. ✪

Manu Sporny: Do you understand what the term refers to? Consumers of credentials, walmart, target, whatever. ✪

Christopher Allen: Absolutely. ✪

Manu Sporny: Let's go through the ecosystem and hear your thoughts on it. Issuers issue credentials, holders receive them put them in a digital wallet on their phone in the cloud, wherever, they pick where they want to store it. ✪

Christopher Allen: Issuers is great, definition is solid. The only thing obviously missing is that if we talk about human trust, when it manifests itself in an enterprise there is a lot of p2p trust ... I have a relationship with Joe at the powerbar company because we've been doing business for a long time together and he's his org have impressed me. ✪

Christopher Allen: There's a little "only these big issuers" whereas I'm interested in the former CTO of PGP being able to issue a statement about working with me in the standards industry vs. verisign ... google almost banned them in Chrome because they were miss handled ... which is a better credential? ✪

Manu Sporny: Right. ✪

Manu Sporny: We want to enable individuals to self-assert and for orgs as well, it's not any harder. Want to cover all of it. ✪

Christopher Allen: What we've heard from Brad Hill is that he doesn't see how that ecosystem could scale with that sort of trust where trust is at the peer-level and it would fall under its own weight. ✪

Christopher Allen: It does have to be constrained by recipes more than it is by the size. If you look at PGP, trusting is often over-interpreted, but fundamentally, do I believe that the party at the other end has properly generated a public+private keypair. That's all it really means. The problem is ... that's not what it really says and it's not precise enough. If the recipe could be what it really is instead of a broader interpretation of what it actually means that would be much better. All of these things that got interpreted into what a PGP credential meant ... that's when it breaks. Having some good recipes that are very precise as to their nomenclature and the rules for that ... that can be done and can scale. Allowing anyone to make a weird, reputation claim in a not-well reputation claim in a weird area that's madness and there's no way to scale that. ✪

Manu Sporny: One person said that one person said that what we're looking at are islands of interoperability here (David Chadwick). ✪

Manu Sporny: Orgs like in the education industry could have their own vocab, etc. ✪

Christopher Allen: There's a fifth category, that's all over the place in the real world. The accreditation ... I don't get diploma from that body but it affects my degree. And having a recipe for multiple bodies is better... that's a "recipe" that you have these types of things. Having a fifth pipe where people are creating these types of recipes are important, a good thing. A recipe for US healthcare and things because of HIPAA and those are different from EU things. ✪

Manu Sporny: With these four players in the ecosystem -- and those other mechanisms that you just described, does the ecosystem make sense to you? ✪

Manu Sporny: Where there can be many of each of these actors in the ecosystem? ✪

Christopher Allen: Yes. With the thing ... the old word was Relying Party for consumers, I agree "consumers" is better than "relying party" but I'm uncomfortable with it. When you're trying to communicate ... it crosses into the people side of the equation. Are they followers, clientèle, or what. ✪

Manu Sporny: We'll mark that and take it back to the group to look at a better name. ✪

Christopher Allen: I also appreciate the difference between an issuer and a curator. I wrote a lot about ratings systems in my blog and on collective choice... including in one of our own ratings systems we got demonstrably better ratings [missed]. If you look at that tech there's a big difference between a rating and a ranking. Issuers are in the same space as rating and ranking requires a lot more and that's where your curators are. They have a very different role in saying "someone's credit rating is greater than that of someone else's" as opposed to "this person has great credit with VISA, their card has already been paid on top." That's a different thing from a curation of a lot of different ratings together. I think that's important and curators may ... because of their power and because in order to do some of their stuff they have to correlate things they may have to have stricter requirements in many ways than issuers. ✪

Manu Sporny: One of things we talk about when we talk about curators ... there are of course some tech proposals on the table, and one says the curator should not be able to track where you're using your credentials (from the consumers), if it can figure that out then it can build a very strong profile of your behavior and what you're doing and we're senstive to that and trying to build that into the protocol. ✪

Christopher Allen: That's also where the power is and to a certain extent the money. If you look at this from "who benefits from it", the curators and consumers are benefitting the most I think. In many ways, issuers are customers ... to a certain extent, serving the community but also users, they can charge a user for an ID, which is very different from a curator who can force someone to do something. ✪

Manu Sporny: Agreed. Switching gears ... technologies that can achieve this kind of ecosystem and address the problem statement. If you were trying to build something to achieve and create this ecosystem... some people are saying the tech already exist and just use SAML, OAuth, OpenID Connect, etc. Do you feel those techs can just be reused to solve this? Are there still some fundamental techs that aren't quite there? ✪

Christopher Allen: I've also been playing around with those same things ... I'm uncomfortable with those things on a variety of different levels, some of which are objective and some that are subjective. On the objective issue side of things, I think that in order provide for non-correlatable identifiers and things of that nature you're going to have to use more complex crypto than what is RSA-based single-key based CA-based architectures are of the JOSE stack. And, they have a relatively constrained format that makes some of those things hard. Obviously, every standard can adapt. That's where we get to the subjective. I just find the JOSE stack to be cumbersome and not ... I just hate the fact that in order to both encrypt and sign something you have to actually put the base64 of the encrypted thing in with it because the JSON isn't consistent in how it's represented. It doesn't even have lists. It just feels ugly to me and that's a subjective thing in many ways. ✪

Manu Sporny: So you don't think that the JOSE stack is suited for an ecosystem like this? ✪

Christopher Allen: It's very inelegant, yes. I also feel that ... I can't tell you ... can it be done? Can it be coerced, probably, but then it will be even uglier. ✪

Christopher Allen: Part of the problem ... switching hats to the cryptographer hat. This was an issue with TLS way back when. Everybody had a different algorithm and hash and MAC mechanism, etc. They all wanted them to be able to slide in and in different ways and combos. But auditing that from a security point of view was *incredibly* hard. And that's kind of how I feel about JOSE. On one hand they have some weird constraints but on the other areas where I *want* to be constrained, they are wild. I want to have two or three things ... or a linear growth in options rather than an exponential growth in options and that's where JOSE is going. ✪

Christopher Allen: And the fact that we need it to do things that it doesn't do now, it will only get worse. They don't do a number of different choices, they do it all as options as woven in and out from each other, very hard to audit. ✪

Manu Sporny: Do you see any technologies on the horizon that can address this type of stuff? ✪

Christopher Allen: Part of the reason why I've tried to get involved with the XDI standard is they are trying to address some of this, I'm not as much of an expert in the graph technologies. Historically graph tech have led to a lot of dead ends, but there are some interesting things in that space to solve these types of problems. I've liked what's been going on with JSON-LD and XDI and the OASIS standard and I haven't quite seen the same coming out of JOSE. ✪

Manu Sporny: Is that with the data model or the digital signature side of things? ✪

Christopher Allen: With the digital signature side of things. The area of null nodes ... whether or not you need to have all the world's data in some kind of graph, cryptography has problems with null nodes. When you don't know about something and you don't want to force that nullness... is a real problem in cryptography. ✪

Manu Sporny: Got it. Jumping to other technologies, OpenID Connect/SAML, could you modify those to get an elegant user-centric system with credentials/claims expressed via them? ✪

Christopher Allen: You *could* but the architecture tends to be very client-server architecture where the server is the key party. And that's just always going to make it difficult. ✪

Manu Sporny: Is the assertion that OpenID Connect/SAML aren't self-sovereign, etc.? ✪

Christopher Allen: Well, they aren't. But how the different pieces are connected together are very oriented towards the server being persistent in ways that limit them. That doesn't mean you can't ... it's a classic thing of it being rooted on HTML. That's how some of these other things arose with issues like requiring a server-centric approach to it. ✪

Manu Sporny: I think what you're asserting is that there's something here with the problem statement and creating this ecosystem would be beneficial and there's no clear tech for it today. ✪

Christopher Allen: That's latter statement -- it's a lot harder with the current tech. What will be most easily adapted to the kinds of changes necessary. Limiting crypto suites ... is a desirable approach, not only doing crypto on the server, ... there's no reason why in TLS you don't theoretically have the server send a credential at all, .... you can get just the same kind of MiTM prevention by having a client send something. It's just that in the 90s the servers were more powerful than the client, so you tried to do all the crypto on the server. That's not true anymore. My iphone has a cryptographic co-processor inside it with a hardened area inside of it. Even IoT ... we're recognizing that you need to have crypto at the leaves. We need to design for that. ✪

Manu Sporny: If this work were to start, particularly which items are important to work on? And where should that happen? Self-sovereign identifiers, protocols, etc. Where should those happen? IETF, W3C? ... So what are the techs and where should they be created? ✪

Christopher Allen: If you start off with self-sovereign ... we have a wallet and a key-management problem. That's very important, I happen to be really biased towards hierarchical trees of keys because they allows a user to have a key completely offline that can't be stolen yet allows them to create other keys and delegate and let them do other things. I can let my phone do a bunch of things on my behalf, but if it's stolen I can create a new subkey very easily. I feel like that it's a fundamental thing to design that from the beginning to support that type of functionality. There are other benefits you get, for instance, I can give the company I'm renting my apartment from an identifier -- and the company I'm getting the power from ... and give them each a different identifier and maybe they can't correlate (maybe a bad example because they both have my physical address). My email provider doesn't need to know those things ... if those two companies share information those two identifiers wouldn't let them correlate and say "oh, this is the same party." That's a good thing for hierarchical keys. One of things with ratings systems in general ... a rating is only is good as the point at which it was issued, so time is very important. The persistence of a rating over time is important. ✪

Christopher Allen: That needs to be built in early on. Verifiable proofs of existence in time ... something that was valid 10 years ago may have changed today, but if it's been continuous over that time and never revoked then it has more authority than what was given out today by a new issuer. ✪

Manu Sporny: So some kind of ledger or blockchain based mechanism or history preserving mechanism? ✪

Christopher Allen: I'm not absolutely sure it needs to be a ledger because it has issues of correlation and so on, but it does need to be provable in time. ✪

Manu Sporny: What about identifiers and formats these claims? ✪

Manu Sporny: Are those good work items? ✪

Christopher Allen: http://www.lifewithalacrity.com/2005/12/systems_for_col.html ✪

Christopher Allen: Absolutely. I see a number of good recipes ... there are human issues on recipes. Writing a good rating/ranking system, various other kinds of systems are hard and we need some good use cases and recipes and really understand the problem and one of the first use cases is badges. Maybe simply that you've completed something. Something that is less than a degree but more than ... you've opened a webpage. That there's been some kind of proof that you've read the document and understood it in some fashion is a really early recipe that I think we can design from the human issue perspective and use that to make new recipes and more complex things. ✪

Manu Sporny: Could you clarify what you mean by "recipe"? ✪

Christopher Allen: As an example, there are ... you talk about a JSON object I give you that basically says that I have rated the paper you wrote, the blog post you wrote on a scale of 1-5 as a 3. I can prove to you that that's problematic. 5 star ratings are a bad design, we do them repeated because people have seen them in the past and they are used to them, but they have a number of serious flaws. First off, a lot of people think 3 is the middle. Well, 2.5 is the middle. There is no 2.5 stars. Due to the nature of how you ask the question people are more likely to rate things positively or negatively. An amazon book rating of 4 stars is the low average. That means that your fellow buyers ... less than 50 percentile is a 4 star book. That's not obvious. People see that as "oh that must be a good book." 4.1 or 4.2 is an average rating for an amazon book. These are human sides of reputation, rating, credentials. ✪

Christopher Allen: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/rebranding-web-of-trust.pdf ✪

Christopher Allen: People started doing parties together and people felt obligated to sign other people's keys because they were at the party with you not because you truly believed they generated their key safely. A human factor got in the way. These kinds of human issues are important in the design of what that JSON object looks like. ✪

Manu Sporny: Is there a particular set of tech at trying to address that problem? ✪

Manu Sporny: Or a set of design thinking around how you solve the problem? ✪

Christopher Allen: More the latter, but that being said, "schemas" are powerful. ✪

Christopher Allen: I think that's one of the things ... you have to be careful because schemas can get in the way also, but that's the thing that the Microformats people discovered if are relatively consistent with something that meets the use cases you don't need to be as precise as full-fledged RDF. ✪

Christopher Allen: The schema was somehow more important than perfectly described RDF. Having some good schemas ... having a good complete discussion about "we've thought carefully about this" and there are human factors in reputation systems and UI issues and so forth that need to be accounted for. ✪

Manu Sporny: I think the conclusion we've come to is that the people who design those schemas should be very close to the problem. If you're designing a schema for hospitals, the hospital/community or the people building stuff for them should figure out the schema and the human factors, it shouldn't be some standardization body. The point being that you need to have experts in a particular vertical to do a good job? ✪

Christopher Allen: Right. I agree with that with the caveat that a standards body can basically say "These are some of the steps and perils and pitfalls that you can fall into if you're not careful and here's our advice." ✪

Manu Sporny: Like a best practice around creating schemas. ✪

Christopher Allen: Yeah! ✪

Christopher Allen: And demonstrating some of those areas that can be done, some of the best practices, explain the behind the scenes ... here is why we chose ... a badge is a low-hanging fruit. I have a definition of a badge, why is it relevant, where are their problems, how do we avoid those problems, etc. ✪

Christopher Allen: Good lessons for you when designing your recipe. ✪

Manu Sporny: We're out of time and we really appreciate you staying a few extra minutes. Do you feel like W3C, IETF, OASIS, etc can do this work? ✪

Christopher Allen: The whole standards area. .. I would say IETF 20 years ago but not today. It's not the same it was back then. I personally found W3C a little harder for small companies to be involved with. It's a little bit dominated by the big browser vendors and companies where I'd like to see a little bit broader industry ... non-computer industry backing in there, but they aren't there. ✪

Christopher Allen: I only have limited exposure to OASIS, last 9 months or so. It at least enforces IP stuff and the minimums there to make sure parties will be treated fairly. It's a little too close to the metal there. They are doing interesting work in crypto though. Technically it's not the IETF ... it's the IESG that's doing more crypto stuff. ✪

Manu Sporny: Crypto forum research folks? ✪

Christopher Allen: Yes. ✪

Manu Sporny: Thank you so much for your time today. ✪

Manu Sporny: To be clear you think it's worthwhile to work on this stuff. ✪

Christopher Allen: Yeah. ✪

Manu Sporny: Expressing verifiable claims and so on. ✪

Christopher Allen: Yes. ✪

Manu Sporny: Ok, thanks and have a great week, we'll CC you on this! ✪