W3C home > Mailing lists > Public > public-credentials@w3.org > June 2016

Verifiable Claims Telecon Minutes for 2016-06-08

From: <msporny@digitalbazaar.com>
Date: Sun, 12 Jun 2016 11:04:57 -0400
Message-Id: <1465743897353.0.12357@zoe>
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:


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

  1. Discuss purpose of architecture proposal
  2. Analysis of current document
  3. Identifier registry
  4. Repository
  5. Simplifying Diagram
  Manu Sporny
  Dave Longley and Manu Sporny
  Dave Longley, Adam Lake, Manu Sporny, Dave Crocker, David I. Lehn

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, 
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 
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 
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 
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 

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 
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, 
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 
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 
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 
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 
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 
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 
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 
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 
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 
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 
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 
Received on Sunday, 12 June 2016 15:05:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:53 UTC