- From: <msporny@digitalbazaar.com>
- Date: Sun, 12 Jun 2016 11:04:57 -0400
- To: Web Payments IG <public-webpayments-ig@w3.org>, Credentials CG <public-credentials@w3.org>
Thanks to Dave Longley and Manu Sporny for scribing this week! The minutes for this week's Verifiable Claims telecon are now available: http://w3c.github.io/vctf/meetings/2016-06-08/ Full text of the discussion follows for W3C archival purposes. Audio from the meeting is available as well (link provided below). ---------------------------------------------------------------- Verifiable Claims Telecon Minutes for 2016-06-08 Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Jun/0029.html Topics: 1. Discuss purpose of architecture proposal 2. Analysis of current document 3. Identifier registry 4. Repository 5. Simplifying Diagram Organizer: Manu Sporny Scribe: Dave Longley and Manu Sporny Present: Dave Longley, Adam Lake, Manu Sporny, Dave Crocker, David I. Lehn Audio: http://w3c.github.io/vctf/meetings/2016-06-08/audio.ogg Dave Longley is scribing. Topic: Discuss purpose of architecture proposal Adam Lake: http://w3c.github.io/webpayments-ig/VCTF/architecture/ Adam Lake: Long form version, https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/raw/master/topics-and-advance-readings/a-self-sovereign-identity-architecture.pdf Manu Sporny: We're putting this proposal together because a number of people at W3C requested it. This arch doc is here to quickly inform people about the type of arch we're talking about. I would even go as far to say that our audience for this is technical orgs, specifically members of W3C, or orgs that would become members of W3C if the work takes off. That's really all the background that we need. Manu Sporny: Deadline is the 20th. The WPIG is going to review all this stuff. To catch you up on where we are, we've been talking about Verifiable Claims, they used to be called Credentials, for about 4 years. This used to be in the Web Payments Community Group. It was later split into its own group at the Credentials Community Group, where it incubated for about 18 months. Then the Web Payments Interest Group, official W3C group, started up and it is responsible for coming up with charters for WGs. VC was taken up by the IG and the VC task force was created to come up with the charter and these other docs and we're going to give those docs to the IG and have them read it and then ask them if they will take it to W3C membership for a vote. Manu Sporny: There's a F2F on the first of July. Manu Sporny: That's why we have this deadline. Dave Crocker: This is a hard deadline for getting a group vote on whether to approve the documents in their current form and put it forward to the W3C membership for approval. Dave Crocker: Just trying to understand the broad strokes of this. Assuming it gets approved, what happens after that? Manu Sporny: If approved by IG it goes to W3C management, and they will tell us if they think the membership won't have any objectives. We may have a roadblock there -- if we get buy in from them and can prove we've got consensus over the past 2 years, etc. THen they would put it to a vote by the whole membership 400+ orgs. Manu Sporny: There are two thumbs down we could get, one is from management -- that means we haven't answered some question from them, usually a large member company has an issue they need resolved. Manu Sporny: Management has been unconvinced twice before but has come back with vague requests. Dave Crocker: Thanks. I apologize for not doing this homework sooner. Manu Sporny: There's no way for you to know without us having this conversation. Dave Crocker: I'm trying to figure out a good way for us to navigate here. I have a bunch of questions I'm looking at -- and the stuff I'm looking at has changed dramatically in the past week or two. It's not good or bad it's that there are changes. When something changes that much this quickly it means it hasn't had time to get into people's brains and discussions for them to know how it will be used. Which strikes me exactly as the issue that these votes are trying to consider. Manu Sporny: Let me clarify a bit, I don't believe what we're proposing in this doc has really changed when it comes to the tribal knowledge in this community. When it comes to what was talked about at the design workshop, that's where there are differences. Topic: Analysis of current document Dave Crocker: Right. I tried to make some annotations on the document that you circulated. We didn't get around to talking about those. Any example of a very basic question about this question and a previous one... where's the identity in this? Dave Crocker: Holder, issuer, inspector, storage location -- where's the identity? The entity that the claims are being made about is never mention. Manu Sporny: We've been calling it that the subject. Dave Longley: We can get to that question in particular, i have thoughts Dave Crocker: We have claims that are ... where they come from is clear (the issuer), where they go actually seems less clear. The reason I say that is ... claims go to the holder and are held in the repository. There appeared in the discussions I was around ... upper box currently labeled registry and used to be ledger ... it was a place to go to verify the claims. You could go there to test the accuracy, not the validity, whether an issuer made the claims can be checked. Manu Sporny: Let me explain removing the ledger. The W3C is just starting to look at blockchain tech. End of June workshop. If we walked in there with a ledger as part of the architecture, we could get pushback and it's not a fundamental component of the system. It's not core to the system. The decentralized identifier system registry is just there for claiming identifiers that you can prove you have ownership over. We tried to narrow the scope of the diagram down to the minimum necessary to bootstrap the ecosystem. For every box and arrow you add it's potentially another spec and protocol you have to define. Dave Crocker: The basic simplicity of the architecture I found really appealing. A simpler architecture means we took the time to make it shorter. Manu Sporny is scribing. Dave Longley: I think you mentioned on previous calls - good to have simple diagram to have people consume. Other diagrams might provide more depth/features - other groups of people that want to understand how you break roles down into subroles. For example, holder. Adam Lake: Lost audio Dave Crocker: Looks like i got disconnected. will call back Dave Longley: Holder could be broken down into software agent that moves stuff around. Same thing for requests - single box - single boxes can be broken down into multiple rules. Topic: Identifier registry Dave Crocker: So, I think the question I ended on was - decentralized identifier registry, in current version, is really only and exactly an identifier registry, you check it to see if an identifier is registered and to whom. Dave Longley: We have been trying to make the diagram that we present in general to be as simple as possible. There are other things that can break roles down into other pieces that more advanced parties would like to learn about. We have a simple diagram to figure out how information can move around. We could have other architecture diagrams that explain how that works. Where is the identity? Where are the verifiable claims? Dave Longley: You could actually break this down into subject that claim is about, software agent that moves claims around, repository that is a storage abstraction - furthermore, where they might go might break down into software/hardware that you hold onto as a person, or it could be a public blockchain that you use to hold on for public claims, or you use some other mechanisms to store private information. Dave Longley: There are a number of different pieces that are not necessary for core architecture, but very important for solving more use cases and implementing the system. Same thing is true for party that receives claims - that same role, which we've called 'consumer', 'inspector' could really be a number of subroles... requesting vs. verification of claim. Maybe claim verification can be delegated. Dave Longley: Or it could check a whitelist for a bunch of issuers that it trusts, or it could be that issuers can receive stuff from accredicration bodies. we don't want all of that in the simplest diagram. We have parties that issue credentials, there are parties that control these claims, parties that can request them, and some concept of an identifier that has independent existence - so you have more power/control - store them as you see fit. Dave Longley: All of those things are a part of the core architecture - you could even say you could take out independent existence part and still have the system work (take out Decentralized Identifier Registry). Dave Crocker: The concept of layering - macro-granuality for one version of arch, and one for smaller-granuality.. we want to make sure macro boxes don't change as you go down to the micro-version. Dave Crocker: So, challenge is boxes you have and what labels you have on them. So, for example - registry - for registry and identifiers who own them. Dave Crocker: Yes, that's all that it does. is it going to be something else as you add more detail. If it's going to be something else, then the label is going to be a problem. Dave Crocker: Saying something like decentralized is an implementation issue - better to have architecture not have implementation details. Dave Longley: Another one of these had "oracle" - don't know if that's too generic. Dave Crocker: We came up with Oracle because that box had multiple pieces of functionality - we had functions that were different from the other two. oracle is not a good word, but didn't have much else to replace it with. Reporter might work. Dave Crocker: The other one, the more you and others have talked about the Holder, the more I see it as something more than just a holder. The reality is that it is the entity being identified. Dave Longley: Most of the time that's true, but sometimes it is about another subject. Dave Crocker: I think that's a striking and useful basis for noting that "identity" - the "identity" being identified is a separate box in the architecture and it ought to be distinguished. I think I understand why that didn't happen. Dave Crocker: You can have actors that have different roles at different times. Implementation vs. architecture - two different boxes might be performed by same actor, that's okay - but they don't have to be compressed into one box. Dave Longley: The fact that a single player might have multiple roles shouldn't affect the architecture. Dave Crocker: For holder, you have a descriptive tag to say it manages the registry entry. That doesn't sound like holder to me, it sounds like owner. Dave Longley: We had a certain concept that goes back to self-soverign identity - you're in control of your own claims. The fact that you might employ software agent to do some of these things. We're trying to keep this particular architecture as simple as possible trying to tease out those subtle differences. Manu Sporny: Jsut to quickly why we try to stay away from identity. Very early on we had identity in a number of these documents -- and the response we got back from reviewers was vehement opposition to any work because we were "trying to tackle the identity problem" and W3C absolutely does not want to get involved in that rolling failure that is identity on the Web and the internet. [scribe assist by Dave Longley] Dave Crocker: I do understand the religious wars that go on with that, I used it because I saw "identifier" and that's an easy term and someone owns that and I used "identity" for that. [scribe assist by Dave Longley] Manu Sporny: The thing that the verifiable claim is about is the "subject" of those claims. [scribe assist by Dave Longley] Manu Sporny: But "holder" is a bit different -- there's a part of the architecture that you haven't been exposed to yet. One of them is to design a privacy aware architecture, at no point should the issuer or repo know who you're giving the claim over to. [scribe assist by Dave Longley] Dave Longley: At no point should they know that until you have given consent. Dave Crocker: That's fine -- but not affected by what we're discussing. I think that the arch can show this privacy feature. I think that's a particular bit of insight that someone looking at the arch can tell or not tell. [scribe assist by Dave Longley] Manu Sporny: We haven't figured out how to do it and if you can do it that's great. [scribe assist by Dave Longley] Manu Sporny: I wanted to mention the self-sovereign bit is important. There are things we've put into the diagram, specifically to demonstrate why this is different from SAML or OpenID Connect. [scribe assist by Dave Longley] Manu Sporny: We have orgs that can issue claims, orgs that can request claims, and all of that stuff is supported in OpenID Connect. Most federated systems today -- they don't support two things: the concept of a subject of a verifiable claim can exist independently of an IdP. That can be done through decentralized identifiers -- where anyone can claim an identifier and manage it. That's a core requirement for people to have independent existence. That's why we don't have oracle in here. We wanted to get specific about the key differences here. [scribe assist by Dave Longley] Manu Sporny: In the future we could have oracle in there. [scribe assist by Dave Longley] Dave Crocker: Saying "decentralized" in that box is a marketing function to help viewers of this diagram an essential functioning difference between architectures. [scribe assist by Dave Longley] Dave Crocker: I'm assuming and I think it's really important, that this be something that it helps guide technical people with this. [scribe assist by Dave Longley] Manu Sporny: The W3C AC will look at 15-30 min tops looking at this proposal and there's much more material here. In every one of these docs we want them to understand that this is new, narrowly scoped, and achievable. [scribe assist by Dave Longley] Dave Crocker: Makes sense and also explains why we want to get it down to a few pages. [scribe assist by Dave Longley] Topic: Repository Dave Crocker: A couple of suggestions: For the purposes you've described, you don't need the repo box. It's an internal function to the holder. [scribe assist by Dave Longley] Manu Sporny: The fact that you can separate the repo from the issuer is an important part of the architecture. In most tech today you can't separate those two. [scribe assist by Dave Longley] Dave Crocker: There can be a third party -- even though all access to the info in the repo is through the holder, a really important point -- you want to highlight that it can be an independent third party. [scribe assist by Dave Longley] Dave Crocker: There would be some standard interfaces to it presumably. [scribe assist by Dave Longley] Manu Sporny: Yes. [scribe assist by Dave Longley] Dave Crocker: The same can be said for the inspection function. It can, and I suspect will, to be delegated to an independent third party. [scribe assist by Dave Longley] Dave Longley: I would say that's true, I would expect there to be a standard way to make a request to a user agent and pass on that request to a user agent that works on behalf of the holder so they can fulfill that request. When you're talking about the inspector, you're talking about independent verifiable - standard interface or algorithm that you can run over a credential to determine whether or not something is verified or fails verification. Dave Longley: Are you talking about protocols asking to see if something is verified? Dave Crocker: I was thinking about the latter - 3rd party inspector was standing between the inspector and the party consuming the information - how to model this - better to have this as the entity that's going to consume the information as being directly connected into the rest of the architecture and rest of the inspection function behind delegated. Just as holder may not want to delegate the function. Dave Longley: I agree - don't know if we make the diagram more complicated. Dave Crocker: Same argument for repository is the same argument that should be for inspector. Dave Crocker: I think the argument is the same, functions are different. Dave Longley: Argument is almost the same, don't think it matters if it's in the arch document. Dave Crocker: Fact that the subject is not in here - maybe we can have subject be above registry - one line going to Registry - that will be entity that manages identifier - holder just manages them - arrow from registry to holder - registry from any of the bottom three - needs to go from registry to bottom 3. Issuer, holder, and inspector, all they do is query the registry. Dave Longley is scribing. Manu Sporny: Subject, I would argue is not necessary in the diagram, because we don't really talk about verifiable claims other than having them in the white boxes. I don't know if having subject helps understand or not. To delegate inspection to a third party is absolutely the same, I'm not convinced that it's important to point that out. One of the reasons being that the system is designed so that every website receiving this information ... receiving a claim... they can do a simple check on it, and it seems like if they delegate that it requires more complexity. I don't know if we need to have that discussion at this point. Every box we add we have to depend as being mandatory in the architecture. Topic: Simplifying Diagram Dave Crocker: So I hear you, part of balancing act, want to include enough to be coherent but not too much. Manu Sporny: You could remove repo and the system would still function. You could remove decentralized identifier registry -- but that's not proposed in the first version of the WG at all. We're just talking about data model and syntax. Not talking about protocols yet because it was hot button. Manu Sporny: Creating a decentralized registry was a hot point, creating that at all means you're not ready for standardization -- you need a system that's bootstrapped with a million people, etc. before doing that. Manu Sporny: It's great that you want self-sovereign identity but it's way too early. Dave Crocker: I can't say that I disagree with them, and that gets into the challenge of how conservative this has to be vs. how visionary can this be. Manu Sporny: It can be somewhat visionary -- we just need to make sure that the data model and syntax we create allows for decentralized identifiers to fit in here, but not do it in v1, but allow for v2. Manu Sporny: We want to be able to say "This is where we're headed" ... we're not putting oracles, ledgers, etc. in there -- because while we want those to be parts of the ecosystem in the future, we feel that it would confuse or send W3C AC reps down the wrong path. We want them thinking about the core problem - the first step for VC. We can show them the next step after that, but not expose them to the 10 year plan. Manu Sporny: In general, that's our thinking on it. Manu Sporny: All of that is up for debate. Dave Crocker: I'm trying to understand enough of where things are and what you ahve in mind so that any suggestions take that in. It makes me unclear why you kept the decentralized registry in there. We want to demonstrate the difference between OpenID Connect. Manu Sporny: We want to demonstrate the difference between OpenID Connect. Dave Crocker: The enthusiasm that tends to dominate cool new stuff - it's always cool, but enthusiasm for it gets in the way that less cool, less neat, reliable stuff works. [scribe assist by Manu Sporny] Dave Longley: One reason to have this in here is to demonstrate that the architecture is fundamentally different from existing architectures. This architecture enables new types of innovation - by changing architecture, rearranging mechanism - we can enable innovation - we don't have to say we need this, we can say if we standardize these other parts, in the future, we can standardize in the future how people can innovate. [scribe assist by Manu Sporny] Dave Crocker: Ok, I think I have enough now on what's driving you - start w/ something with as simple as possible - maybe it looks like existing systems - registry - global arbitrator of identifiers. Have a registry - have the subject above it - have issuer, holder, inspector, and that's it. [scribe assist by Manu Sporny] Dave Crocker: That doesn't look exiting - another version has elaborations that we've talked about - tells people where it starts and where it's going and it does it easily. [scribe assist by Manu Sporny] Manu Sporny: On the call yesterday, when I said maybe we have two versions of these diagrams -- that's kind of what I was getting at. First one can show an oversimplified view of where we are and then another one for where we could get in the future. Manu Sporny: The concrete changes you suggested sounded interesting to me. I can see how could break out those boxes and show how we get from one system to the next. Manu Sporny: Do we show both of these? Dave Crocker: You've already indicated some marketing/sales problem if you only show the simple one - how is this different? [scribe assist by Manu Sporny] Dave Crocker: You have marketing/sales problems with only the simple one. Manu Sporny is scribing. Dave Crocker: The whole point behind simple one is that it's not supposed to be different... Dave Longley: Important to show both - this is kinda how things work together, subtle differences, this is where we can head in the future - purpose is to build a data model and syntax around claims that allows this future visionary architecture to arise - once people start using data model/format, people can innovate on other components. Manu Sporny: So dcrocker, you're saying, put subject in there, switch the errors with the registry, put repo into the holder and leave it there/don't show it, or break repository out and break third party verifier out of it. [scribe assist by Dave Longley] Dave Longley: That's a core architectural change - separation from issuer - separate registry - identifier is integrated into identity providers (issuer-repository) Dave Longley: By breaking these pieces out, that's what's core to building these new systems in the future. Adam Lake: Maybe we use just "identifier Registry" to be identity provider agnostic but the architecture allows for decentralized registries. Dave Crocker: I'm so used to thinking as DNS as global registry, I keep forgetting that we have all sorts of identifier creation in various systems - Twitter username, for example. I hadn't thought about this as an enhancement - you get to make point about independent registration Dave Longley: I like that as well - but how do we stop people from talking about implementation details. We want to break those things apart... Dave Crocker: The short answer is URI are an existence proof for global identifier registration service - and in fact, early version will use something like that. It may have limitations, but it's a well understood construct. The identifiers are just URIs. Dave Longley: Yes, I think that's okay - URIs... Adam Lake: I'm working on document, observing mostly, appreciate feedback/pushback - helps us understand what other folks might push back on. Dave Crocker: What I'm inclined to offer is to make a pass on the document and make changes that you can look at and think about.
Received on Sunday, 12 June 2016 15:05:22 UTC