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

Verifiable Claims Telecon Minutes for 2016-06-14

From: <msporny@digitalbazaar.com>
Date: Tue, 14 Jun 2016 13:42:28 -0400
Message-Id: <1465926148551.0.7567@zoe>
To: Web Payments IG <public-webpayments-ig@w3.org>, Credentials CG <public-credentials@w3.org>
Thanks to Brian Sletten for scribing this week! The minutes
for this week's Verifiable Claims telecon are now available:

http://w3c.github.io/vctf/meetings/2016-06-14/

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

Agenda:
  https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Jun/0061.html
Topics:
  1. Terminology Poll
  2. Implementer Commitment Summary
  3. Verifiable Claims Architecture
  4. Primer
  5. Data Model Specification
  6. Use Cases
  7. Items that are "Good Enough" for Review
Organizer:
  Manu Sporny
Scribe:
  Brian Sletten
Present:
  Brian Sletten, Manu Sporny, Stuart Sutton, Shane McCarron, Dave 
  Crocker, Dave Longley, Christopher Allen, Drummond Reed, Joe 
  Andrieu, Dan Burnett, Adam Lake, Carla Casilli, Matt Stone, Gregg 
  Kellogg, Richard Varn, Rob Trainer, David I. Lehn, Darrell Duane, 
  Alok Bhargava, Adam Madlin, Colleen Kennedy, Eric Korb, Rebecca 
  Simmons, Bill DeLorenzo, Les Chasen
Audio:
  http://w3c.github.io/vctf/meetings/2016-06-14/audio.ogg

Brian Sletten is scribing.

Topic: Terminology Poll

Manu Sporny: https://www.opavote.com/vote/6609369386975232
Manu Sporny:  Last week we called a poll on terminology. If you 
  have not filled out the poll please do so as soon as possible. It 
  closes tomorrow. We need anyone who has an opinion to weigh in on 
  that.
Manu Sporny:  We are not trying to make permanent decisions, we 
  are just trying align our terminology before sending the 
  documents off.
Manu Sporny:  We did it this way because we were pressed for time 
  and didn't have time for multiple polls.
Stuart Sutton: Anyone else having incoherent sound?
Manu Sporny:  Response is pretty good but still submit your votes 
  for the poll.

Topic: Implementer Commitment Summary

Manu Sporny: 
  http://w3c.github.io/webpayments-ig/VCTF/implementers/
Manu Sporny:  For those that filled out the initial poll on 
  whether or not they agree with the direction of the work, problem 
  statement, deliverables, etc. A number of people are said that 
  they are interested in implementing the standards. We have a new  
  poll that closes  quickly with a healthy set of responses so far. 
  We are looking for commitment by  organizations with big reach to 
  express interest in deploying these standards.

Topic: Verifiable Claims Architecture

Manu Sporny:  This is the primary discussion point for today. We 
  have between three and four proposals on the table depending on 
  how you look at it.
Manu Sporny:  We have used an architecture for a long time that 
  we've discussed but have never written up in a concise way. We 
  want to give the W3C Membership something that they can easily 
  understand what we are doing.
Manu Sporny: 
  http://w3c.github.io/webpayments-ig/VCTF/architecture/
Manu Sporny:  We have circled this diagram to a number of people 
  and collected that input to create a separate diagram to find 
  consensus among the positions. We want a coherent view of the 
  architecture.
Manu Sporny:  One of the things we found was that it was very 
  difficult and label all of the information. The diagram got very 
  cluttered. The second set of comments were about the information 
  flow diagrams (directionality, push/pull, perspective, etc.)
Dave Longley: 
  https://docs.google.com/drawings/d/1M2cfMOCbXmMhg8Ar2YeCiRhMsJK-hzkCf1L_hJKMOHY/edit
Manu Sporny:  In order to try to reconcile this, we tried 
  multiple approaches. dlongley sat down and took a look at 
  creating a unified diagram with the information flows (at this 
  link).
Shane McCarron: I think that the arrow directions is a red 
  herring
Manu Sporny: 
  http://w3c.github.io/webpayments-ig/VCTF/architecture/v4/
Manu Sporny:  A number of people responded to this. It's an 
  improvement but raised the question about whether we are trying 
  to do too much with one diagram.
Manu Sporny: 
  http://w3c.github.io/webpayments-ig/VCTF/architecture/v4/#verifiable-claim
Manu Sporny:  One of the things that we weren't doing in the 
  other documents was talking about what a verifiable claim looked 
  like. We now have a graphic around what goes into a verifiable 
  claim.
Manu Sporny: 
  http://w3c.github.io/webpayments-ig/VCTF/architecture/v4/#basic-architecture
Manu Sporny: Flow diagrams here: 
  http://w3c.github.io/webpayments-ig/VCTF/architecture/v4/#use-case
Dave Crocker: Did my posting, this morning, commenting on arrows 
  and having the holder register the identifier, make it into the 
  mailing list?  (I don't seem to be seeing list traffic.)
Manu Sporny:  The block diagram attempts to ignore arrows or 
  labels on the messages. It says here are the roles in the system. 
  If you go to the exemplary use case, we have flow diagrams.
Dave Crocker:  It didn't make it to the list yet (awaiting 
  approval by a human i presume) [scribe assist by Dave Longley]
Manu Sporny:  This is where we try to label the flows in the 
  messages.
Dave Longley: (Since it was your first email to the list)
Dave Crocker: So, I'll apologize for posting it here, but think 
  it's useful for the discussion...
Manu Sporny:  We tried make it into more of a narrative than 
  explain everything in the same image.
Dave Crocker: Diagram lines:      An architecture details 
  actors/roles and the relationships among them.  A relationship is 
  more than a line; it has directionality in order to show 
  something about the flow of information.      Flow of information 
  is a higher-level construct, having to do with the transfer of 
  content payload and is different from the lower-level construct 
  of protocol interaction, such as push or pull, which are the 
  underlying mechanism for effecting t[CUT]
Shane McCarron: I have a weird concern with the diagrams vs the 
  diagrams elsewhere
Dave Crocker:  I think the arrow issue isn't a red herring and 
  helps a reader of the diagram can be extremely helpful to 
  understand what is being done and accomplished. The question is 
  what level of useful things you are showing (abstractions vs 
  protocol). I also think the term Holder conflates the Subject 
  with the registrar of the claim.
Christopher Allen:  Scribe note, I missed what Chris said about 
  Information Flow vs Knowledge Flow.
Drummond Reed: I like the diagrams as I'm reviewing them now.
Joe Andrieu:  In these conversations, the unity between the 
  holder and the person representing the claims is confusing to me. 
  It seems to me that the claim need not be held by the person 
  asserting it.
Joe Andrieu:  And by held I mean "Who controls the digital 
  representation of the claim?"
Dan Burnett: I like the diagrams.  If I had to choose one, it 
  would be v4 because it seems to be the right level of detail
Shane McCarron: This should not matter from an architectural 
  perspective
Drummond Reed: Isn't that the purpose of the term "Holder" and 
  the term "Subject" - one manages the claim and one is the actual 
  subject of the claim.
Manu Sporny:  The terminology is not nailed down. You can hold 
  onto a set of claims about something else. It is still a topic of 
  discussion to best model what those things are. The data model is 
  flexible. No decisions have been made on the right way to model 
  these.
Manu Sporny: Drummond, yes, but /which/ diagrams do you like :)
Dave Longley:  I think generally in this architecture. The role 
  that has agency is the Holder. They are the one who goes out and 
  acquires a claim about a Subject. They also present it. The 
  Subject has no agency generally.
Drummond Reed: I like them all (seriously)
Manu Sporny: (The original /architecture/ ones? or the 
  /architecture/v4 ones? or the /architecture/v4/details/ ones?) 
Dan Burnett: Agree with dlongley about Holder vs Subject.  My cat 
  or my car could be a Subject but likely won't be a Holder.
Drummond Reed: Sorry, I'll be more specific: I like Dave's new 
  "overall" diagram, and I like the /architecture/v4/details/ 
  sequence diagrams.
Adam Lake: Does the subject ALWAYS have an identifier?
Dave Longley:  On top of that, we have the concept of a 
  credential repository that we have not shown in the architecture 
  diagram because it is part of the Holder. It doesn't have to be 
  the same party of the Holder. It is the party that you store your 
  credentials in, but that could be swapped out. The Holder is the 
  main role for registering and presenting though.
Manu Sporny: Adamlake, yes
Manu Sporny: Adamlake, the identifier may be different.
Carla Casilli: +1 On what dlongley is saying
Matt Stone: It's Al Gore's big lockbox :)
Manu Sporny: Adamlake, meaning - there are many types of 
  identifiers.
Dave Longley:  They'd have the ability to cryptographically prove 
  ... [scribe assist by Manu Sporny]
Dave Longley:  At that issuer, they provide proof in some way - 
  other claims that they possess - other information, private 
  website, other channel, take a test, doesn't really matter. After 
  issuer evaluates them, party says who they are, proof over 
  subject identifier - claim for subject identifier, hand it over 
  to identifier. [scribe assist by Manu Sporny]
Dave Longley:  Give it to whatever consumer they want to. [scribe 
  assist by Manu Sporny]
Dave Crocker:  Question has to do w/ recipient of the claims - 
  whoever contacts the holder, gets the claim from the holder, who 
  is the subject? [scribe assist by Manu Sporny]
Carla Casilli: The subject + holder = some form of identity 
  assertion
Dave Longley:  Who is the claim about - establish identity about 
  subject. 1) proof of posession of subject identifier  and 2) look 
  at claims and where they come from. Claims about pieces of 
  information that they care about. [scribe assist by Manu Sporny]
Dave Longley:  If claim is made by consumer trusts, they can do 
  something w/ that piece of information. [scribe assist by Manu 
  Sporny]
Drummond Reed: "The only way the recipient knows who the subject 
  is via the claims" - +1
Manu Sporny: Dcrocker's audio breaking up
Dave Crocker:  The model you're describing - collection of claims 
  to refer to how they refer to -popular reference, where has that 
  model been demonstrated to be viable at scale. [scribe assist by 
  Manu Sporny]
Dave Longley:  Generally speaking, the notion of someone visiting 
  a website today and asserting who they are to a website, previous 
  relationship with the website. [scribe assist by Manu Sporny]
Dave Longley:  All we're doing with this model is shifting trust 
  - from the website to a 3rd party. Receive claim from issuer - 
  converting to consumer, consumer trusts - can take test, get a 
  good score - all authentication systems in popular systems use 
  that. [scribe assist by Manu Sporny]
Dave Longley:  Google/Twitter/Facebook - this model is no 
  different from that model -  [scribe assist by Manu Sporny]
Dave Crocker:  This model is completely different - what you're 
  talking about here is building a new trust model on top of that, 
  and it's more distributed in ways than Facebook. [scribe assist 
  by Manu Sporny]
Dave Longley:  It is true that this is new - if your question is 
  "Has this been proven", the answer is "no, because we're building 
  it now." [scribe assist by Manu Sporny]
Manu Sporny:  We are way off in the weeds. What we are trying to 
  do is make some decisions on the set of documents to present to 
  the W3C. We have spent the last 10 min talking about things we've 
  discussed in the last year. We only have this call to make 
  decisions to get the documents to the W3C in the next two weeks. 
  Let's realign on discussing the documents.
Christopher Allen:  My preference: Simple arrows are better.
Manu Sporny:  Is there a preference for arrows in the diagram? Is 
  an image of the structure of a verifiable claim helpful (and 
  should we include it)? Are flow diagrams that show an exemplary 
  use case helpful? Is a document that attempts to combine those 
  things (kind of what dcrocker is asking for and what dlongley has 
  done) helpful?
Matt Stone: +1 For content of a verifiable claim, +1 exemplary 
  use diagrams, +0 on block diagram w/out arrows in the block 
  diagram. haven't captured the essence of the architecture.
Gregg Kellogg:  The answer to all four of those questions is 
  "yes". I like the v4 versions. I am not sure I prefer the 
  detailed versions. I do think the sequence diagrams helps work 
  through things. I think the all-in-one diagram is a useful way of 
  uni
Richard Varn:  I think the detailed is best, the V4 is adequate.  
  I like seeing the big picture with all the participating entities 
  named such as repository
Dan Burnett: (Just got dropped)
Gregg Kellogg:  Unifying all of the diagrams.
Drummond Reed:  I like the consolidated diagram for the 
  conceptual picture. I like the sequence diagrams because they are 
  detailed enough.
Dave Longley: Problem is with keeping this short
Manu Sporny: 
  http://w3c.github.io/webpayments-ig/VCTF/architecture/v4/
Manu Sporny: 
  http://w3c.github.io/webpayments-ig/VCTF/architecture/v4/detailed/
Dave Longley: Here's the link with all in one: 
  https://docs.google.com/drawings/d/1M2cfMOCbXmMhg8Ar2YeCiRhMsJK-hzkCf1L_hJKMOHY/edit
Dan Burnett: (I'm back on).
Carla Casilli: Prefer the v4 diagram and the v4 detailed for 
  internal needs / further explanation needs.
Manu Sporny:  The reason for the detailed diagrams was that 
  dcrocker had put forth the idea of a basic architecture and a 
  more detailed version. We tried to distill it to its essence and 
  then see the more moving parts in the detailed version. I think 
  the proposal is to go with the v4 version and link to the 
  detailed version.
Dan Burnett:  The data model will show what goes into a 
  verifiable claim. I still think it useful to have a high level 
  view of that in the architecture diagram. But, I wanted to let 
  people know that there will be another document that details 
  that.
Christopher Allen:  This is intended for AC people who deal with 
  PDFs, maybe not detailed architectural diagrams.
Manu Sporny:  We are trying to keep it high level to keep that in 
  mind.
Manu Sporny:  We are trying to take the input and deal with it in 
  the short term we have. Several people have been uncomfortable 
  with the amount of churn recently.
Dan Burnett: Chris, we know that most of the folks will not want 
  to see low-level details.  in practice, though, unless you have 
  more details available (in other docs such as data-model) enough 
  readers will complain that it could derail progress
Dave Longley: 
  https://docs.google.com/drawings/d/1M2cfMOCbXmMhg8Ar2YeCiRhMsJK-hzkCf1L_hJKMOHY/edit
Matt Stone:  The thing that makes me uncomfortable about the 
  simplified view is that it feels empty and doesn't show me how 
  things are interacting. I am stuck thinking "What am supposed to 
  take away here?"
Dave Longley:  Did you see the other diagram where we had these 
  details?
Manu Sporny: Proposal is looking at 
  http://w3c.github.io/webpayments-ig/VCTF/architecture/v4/
Manu Sporny:  The proposal take the v4 document with dcrocker's 
  changes, keep section 2, we are going to be standardizing the 
  structure in the first phase, section 3: replace the diagram with 
  dlongley's diagram and then we leave section 4 alone.
Drummond Reed: +1 To manu's proposal
Dan Burnett: +1 To manu's proposal
Matt Stone: +1 On the concept of  the dlongley diagram - I like 
  the suggestion of ordinality of the relation
Matt Stone:  I think what you are saying is where I was going. I 
  like this concept of the ordinality of the relationship within 
  the lifecycle of a claim. It influences some understanding of 
  what is going on under the covers.
Dave Longley: +1 To the proposal
Brian Sletten: +1
Carla Casilli: +1 On manu's proposal
Gregg Kellogg: +1
Stuart Sutton: +1 On Manu's proposal
Shane McCarron: +1 To manus proposal.
Dave Crocker:  I think it is pretty good. I don't have a strong 
  feeling about the diagrams. I understand what you are going. A 
  first exposure to someone without a background is appropriate 
  with the simplified view. I think the detailed version is a bit 
  busy.
Manu Sporny:  Do you think you could produce a diagram that takes 
  what dlongley has done and puts it in the way you want to see it? 
  (If it isn't the first diagram you produced)
Dave Crocker:  I will take a pass and see if I come up with 
  anything.
Dave Longley: Was just going to say that the arrows kind of 
  double as information flow and "actions" taken by the roles in 
  the diagram
Manu Sporny:  We are going to move forward with this proposal. 
  Not a lot of screaming and plenty of +1's.
Dave Longley: But agree it's more busy than we'd like.
Manu Sporny:  Any disagreement? No? We're moving on.
Matt Stone: +1 To proposal

Topic: Primer

Manu Sporny: http://bit.ly/1tn2v2a
Manu Sporny:  Adam, give us a quick update on the primer.
Adam Lake:  I think it is 90% complete. I'll send another request 
  for feedback to the mailing list. It will probably be the first 
  thing AC reps read.

Topic: Data Model Specification

Manu Sporny:  We'll take feedback for the next two days and then 
  turn it into an HTML page.
Manu Sporny: http://opencreds.org/specs/source/claims-data-model/
Dan Burnett:  I haven't done any updates in the past week because 
  the focus has been on the architecture diagrams. I will update 
  the data model to reflect what is in the architecture document 
  with respect to the structure of the verifiable claims.
Dan Burnett:  I try to have a version ready before the call, I'll 
  do the update and send it out by email. Keep an eye open for a 
  new version. I think the document is close to complete.

Topic: Use Cases

Manu Sporny: http://w3c.github.io/webpayments-ig/VCTF/use-cases/
Shane McCarron:  I haven't done anything. I have the stuff from 
  JoeAndrieu which is great. I am trying to integrate the new 
  terminology, update or throw out my diagrams and added in the 
  user perspective.
Manu Sporny:  The data model spec and the use cases are the 
  documents that need to nail them down the least. It will be 
  cleaned up in the Working Group.
Joe Andrieu:  It seems some requirements might be a useful 
  output. I am not yet convinced that we directly have a means to 
  address the ID2020 topics. We might, but I don't think we 
  understand well enough whether we do.
Manu Sporny:  We should address that in the Community Group. 
  Working Groups usually take requirements as an input. The 
  requirements now are about a data model and a set of syntaxes.
Manu Sporny:  I have been unable to get use cases and 
  requirements out of folks that were there. We'll continue to work 
  on requirements in the CG and then hand it over to the WG.
Manu Sporny:  The onus is on the ID2020 folks to get the 
  requirements and use cases to us.
Dave Longley: Rechartering the WG.
Shane McCarron: The problem is that the requirements do not in 
  general control the output of a working group once it is launched

Topic: Items that are "Good Enough" for Review

Manu Sporny: Charter - 
  http://w3c.github.io/webpayments-ig/VCTF/charter/
Manu Sporny: Verifiable Claims Charter FAQ - 
  http://w3c.github.io/webpayments-ig/VCTF/charter/faq.html
Manu Sporny: Demonstration of Support - 
  http://w3c.github.io/webpayments-ig/VCTF/support/
Dan Burnett: Agree with Shane.  The requirements process is 
  usually only valuable in W3C groups to help people largely agree 
  on how to proceed.  We can always do more of that as necessary 
  within the WG as long as we don't exceed the charter
Manu Sporny:  Proposal: The Charter, FAQ and Demonstration of 
  Support documents are done, please review them. Please vote if 
  you haven't on the poll. Send in any comments as soon as 
  possible.
Received on Tuesday, 14 June 2016 17:42:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:29 UTC