The Verifiable Claims Task Force

A Task Force of the Web Payments Interest Group

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 Log
Brian Sletten is scribing.

Topic: Terminology Poll

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: 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: 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.)
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: 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: 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.
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
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
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: 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: 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.
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

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: 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.