Verifiable Claims Telecon

Manu Sporny: This is main landing page for the proposal. It's the first page anyone reviewing the proposal will see. It's in the order we want them to review. They only need to review at minimum two documents. Adam Lake is working on the primer. Should be a quick read. Draft charter document must be read by AC reps. Then there is a bunch of supporting documentation.

... any questions about landing page? (none)

Topic: Verifiable Claims Use Cases Review

Manu Sporny: http://w3c.github.io/webpayments-ig/VCTF/use-cases/

... joe did extensive review of use cases. will summarize here.

Manu Sporny: This is the document that Joe is talking about - the review he did: https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Jun/att-0018/Requirements_Modeling_for_the_Verifiable_Claims_Task_Force.pdf

Joe Kaplan: Writeup describes what we did. First half of doc gives first impressions, mainly wanting to see the human value. (Better) titles would help with this. We gave suggestions. Some of them are simple and functional such as "send money", but "lazy doctor" is a better example of what we were after.

... we then put together some different requirements and models. First, a user needs map -- a visual representation of needs. If there isn't a number in the diagram it's because it wasn't already in the use cases document.

Manu Sporny: We're looking at the top of page 6 now

Nate Otto: +1 Digital Passport, Digital Birth Certificate, Air Travel scenarios

Manu Sporny: We're looking at the top of page 7 now...

... terminology was an issue we raised as well. also, sometimes use cases are from problem domain and some are from solution domain. separating these two types might be helpful. Not clear how right to be forgotten is supported in getClaim. (missed something else about claims)

Matt Stone: +1 On document in general!

Nate Otto: Amend Claim seems to go along with Revoke Claim without introducing major additional techncal scope.

... showed full life cycle and sample use case that was independent of technology.

Nate Otto: Forget claim is an interesting one (page 8), though why is there an additional actor "Subject" for that action. What's the difference between that and Recipient? Shouldn't it be Recipient?

Manu Sporny: Great stuff. Would love to see virtually all of these changes incorporated into the document if time permits.

Nate Otto: +"Busy Doctor" instead of "Lazy Doctor"--She can't be lazy, just doesn't have enough time because we haven't yet reduced all the medical records and insurance claim paperwork.

... short scenario titles would be great. The graphic would be great at the beginning to map the verticals. The role stuff and mappings to user tasks are excellent as well.

Shane McCarron: I don't need sleep :) yes, this is great. It's wonderful to have this outside-the-box review. Will work with Joe offline to incorporate. We have two requirements documents in our hands; do we still need both?

Manu Sporny: Yes, but for now getting the images into the brief one would be very helpful.

... eventually we will want to merge back into the larger document. Let's focus on getting the images in first into the short doc.

Dave Longley: +1 For "Busy Doctor" (or a similar alternative adjective to "Lazy")

Shane McCarron: And we should also move a bunch of the cruft at the front into an appendix. thanks Joe!

Topic: Verifiable Claims Charter

Manu Sporny: http://w3c.github.io/webpayments-ig/VCTF/charter/

Matt Stone: +1 On not "lazy" doctor (being the spouse of a Dr, I know it's hard to be lazy and get to be a Dr. :) ) -- there are definitly bad Drs. that a patient would want to know about.

Nate Otto: @Dlongley yikes, that's a new mismatch with open badges, which is very clear that a "recipient" is the entity a claim is about.

Manu Sporny: I integrated all of the survey feedback. There wasn't much that changed, but what changed was important. Liaison relationships, clarified that we are not proposing browser APIs but that could be added after the data model work is done if group wants. I think the charter is ready for others to review. Probably ready for IG to review. Everyone please review now.

Topic: Verifiable Claims Charter FAQ

Matt Stone: +1 Overworked (if it's about insurers and EMR) and +1 negligent (if it's about complication rate) :)

Manu Sporny: http://w3c.github.io/webpayments-ig/VCTF/charter/faq.html

Shane McCarron: Note that the wiki should be updated too... https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/Credentials

... we have expanded it and attempted to answer every question raised in the survey. We may reorganize a bit and add a few more questions, but the faq is largely complete. Any questions?

... and yes, the wiki needs updating.

... the wiki should probably just point to the landing page.

Topic: Architecture Summary

Manu Sporny: http://w3c.github.io/webpayments-ig/VCTF/architecture/

... Adam Lake has been working on this.

Adam Lake: Mainly boiling down the 15 page original to 2 pages. Took out public ledger, changed to decentralized id registry. Only question I have is whether participant benefits should be included.

Nate Otto: @Dlongley the term "inspector" and "holder" appears on this diagram, where we saw "recipient" and "subject" on the last one. Are these analogues?

Shane McCarron: (NOTE: Updated wiki page to point to the github repo)

Manu Sporny: Dave Crocker has also been looking at this with others. My hope is that the current doc is stable enough for now. Dave, this is what you should work with for now. How might you want to change or modify it?

Nate Otto: "Inspector":"consumer", "holder":"recipient", "subject" (the party the claim is about, usually the "holder"/"recipient", but may not be) [scribe assist by Dave Longley]

Dave Crocker: Good question. I'm not sure. The differences from the prior doc seem significant. I want to be careful how to proceed since I'm new and there is a tight deadline. What is the best way for me to help?

Manu Sporny: You, Adam, and I can have a call (and anyone else who wants to join)

... we could also have multiple architectures.

Dave Crocker: Bad idea. let's discuss only one architecture.

Manu Sporny: Will let the group know when our call is and record it for the group.

Nate Otto: I'm fine with "inspector":"consumer" and "holder":"recipient":"subject" as mostly equivalent sets, I just don't want "recipient" moving between the different definition sets.

Nate Otto: Been chatting with DaveC about roles in the document. The work 'recipient' seems to be changing defintions.

Manu Sporny: Yes, that's the next agenda topic. We need some final decisions on terminology.

Manu Sporny is scribing.

Topic: Verifiable Claims Data Model Specification

Dan Burnett: http://opencreds.org/specs/source/claims-data-model/

Dave Crocker: Finding an hour for arch -- hmmm, and terminlogy? -- discussion: my schedule is quite open this week, through Friday, except mid-afternoon today (pacific time) and around noontime on Friday.

Dan Burnett: Two main modifications on past week - adding an introduction and adding a UML diagram. The introduction, I pulled from the previous document.

Dan Burnett: I'd like people to look at the introduction - ideally, remove a lot of that and point somewhere else, that would be ideal. Maps rest of document.

Dan Burnett: Steven Rowat had some appropriate questions/concerns about terminology - he's getting more information from other documents now, clearly there is a lot of terminology I'm going to have to make consistent in the document. One of his suggestions was to add a diagram of some sort. I don't know if this is the optimal diagram... it's UML-like, attempt to provide another representation other than text prose.

Dan Burnett: The challenge here is different orgs and different people that want to use different syntactic representations. we've talked about JSON, JSON-LD and WebIDL - we need to be able to talk about our data model using not those three - speaking more generically about data model.

Dan Burnett: Yes, some people use serialization - many people would argue w/ me if I said WebIDL is a serialization - syntax, grammar weasel words to work around that.

Dan Burnett: Looking for feedback - we need to discuss TBD Credential next - it's a term that I can use to remove claims dataset / identity data set.

Joe Andrieu: In the data model would it be possible to use a term other than identity as defined? That term is excessively overloaded in the industry?

Joe Andrieu: "Profile"? ... it's hard to find the right term there. [scribe assist by Dave Longley]

Dan Burnett: For the JSON-LD, I need to come up with a closer to real example - still need to do that, have some examples. Brian Sletten asked me why there is a mention of XML once and then never again - we might list XML as a syntax that you can use. The reason there is only a mention of it is because no one has sent me examples. If someone could send me other examples in XML, I can link the general instructions in XML. If no one has time to send that, I'll probably change mention of XML to be a parenthetical.

Dan Burnett: In no way do we want just JSON and WebIDL the only way to represent the data model.

Joe Andrieu: Yes. It's the focus of the other paper I'm working on from the ID2020 workshop... not easy to shift the conversation

Dave Longley: "Identity" fits here... always a problem with it in the industry, not sure what to do about it (we've had many conversations around trying to figure that out)

Shane McCarron: Dan, you mentioned there is terminology conflicts between your document - you're worried about conflict on terms - or in terminology discussion?

Dan Burnett: Now is probably the right time, practical issue - we need to define some terms in general, what is identity, what is entity, what is a claim, what is TBD Credential.

Dan Burnett: Then practically, in the document, we use those to use things in the data model. I have terminology and then I have actual objects to mean a structure in a data model, or in WebIDL, a specific interface name. ReSpec does some nice things for linking, but in my case, duplicates for all definitions. Consequence of the document itself.

Dan Burnett: Not quite sure how to deal w/ that yet.

Gregg Kellogg: Note that we do have a central repository of term definnitions: http://opencreds.org/specs/source/glossary/

Topic: Terminology Conflicts

Dan Burnett is scribing.

Joe Andrieu: Fwiw, here is the starting topic paper on "identity" from the ID2020 design workshop https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/blob/master/topics-and-advance-readings/Identity%20is%20a%20Phenomenon%20Not%20a%20Property.Andrieu.2016.pdf

Manu Sporny: Terminology discussions take forever. Let's see what we can do.

... we need to align our use of terminology across documents. There are specific terms that are the primary problems. User-centric and self-sovereign is one conflict. Another is 'consumer' vs 'inspector'. Another is the 'TBD credential'.

... prefer that we not open the general floodgates. Want instead to have a single proposal that gets us an improvement over what we have now.

... We only have two weeks to finalize this.

Manu Sporny: Another term is "recipient" -- has to be decided. [scribe assist by Nate Otto]

... we will first discuss user-centric vs self-sovereign

... will ask people to +1/-1 each proposal

... we have been using the term user-centric for a long time in this group. in the identity realm it means something different than what we mean and it has caused confusion.

... a new term that has been proposed is self-sovereign. meaning that users have full control over identifiers and where their verifiable claims are stored.

... this was used in ID2020, even to the point where UN ambassadors were using it!

... proposal is to align all documents to use this term.

Adam Lake: Seems like we have less time to decide on terms because we need to give authors time to update all documents

Joe Andrieu: Can non-members vote here?

Manu Sporny: Yes, everyone may participate.

PROPOSAL: Adopt self-sovereign terminology over user-centric terminology.

Shane McCarron: +1

Matt Stone: +1 Self-sovereign

Gregg Kellogg: +1

Dave Longley: +1

Dave Crocker: +1 Ssi

Nate Otto: +1

Dan Burnett: +1

David Ezell: +1

Kerri Lemoie: +1 Self-sovereign

Eric Korb: -1

Richard Varn: +1

Les Chasen: +1

Joe Andrieu: +1 Self soveriegn

Jason Weaver: +1

Brian Sletten: +1

Manu Sporny: Eric, can you explain your -1?

Eric Korb: Just find user-centric easier to explain, personal preference mainly

Manu Sporny: Eric, can you live with adoption self-sovereign?

Eric Korb: Yes

Carla Casilli: I like the term self-sovereign but am concerned with the burden of supporting a new term

Eric Korb: 34B is korb, back in

Carla Casilli: Okay +1 on self sovereign w/ the proposed pushback

Manu Sporny: If we use user-centric, we will confuse the identity community. if we use self-sovereign it has the problem of being new.

RESOLUTION: Adopt self-sovereign terminology over user-centric terminology.

Dave Crocker: IMO, "user centric" is friendly but vague. It could mean almost anything. Whereas "self-sovereign" has a narrow semantic. The specifics need less explanation.

Shane McCarron: Agenda+ webpayments-ig github repo confusion

Manu Sporny: Consumer vs inspector

... this is a gatekeeper that gives you access to a resource.

Joe Andrieu: Is "recipient" on the table for Consumer/Inspector?

Matt Stone: -1 Recipient

Carla Casilli: +1 For inspector

Dave Crocker: From the New York discussion, it was noted that the recipient/consumer of the information might delegate the actual inspection process to a third-party. That suggests using the broader term as the basic one.

Matt Stone: Recipient may be confused with the earner who is receiving the credential

Dave Longley: Joe Andrieu, "recipient" was previously used in this group (and in open badges) to refer to the "holder/subject" party

... Credentials CG and Payments IG have used the term consumer for this. Concerns have been raised that this means consumer of a website or product. We tried out inspector in New York. Didn't seem to cause problems.

... DaveC pointed out that inspector and receiver might be two different parties.

Joe Andrieu: I see. Yes, that would be confusing.

... questions or concerns over these two choices?

Nate Otto: Consumer is clearer to me.

Richard Varn: +1 For credential inspector. describes the actor and sounds official. avoids confusion with the many ideas of what a consumer is

Matt Stone: +1 Inspector - more narrow

Richard Varn: I meant claim, not credential

Dave Crocker: ...And thinking some more... consumer is such a generic term, whereas inspector is narrow and more intuitive. we could defer the issue of possibly delegating the evaluation process to a third party.

Gregg Kellogg: Consumer is a general term of art that is fairly well understood. Inventing a new term 'inspector' can cause problems as well. I believe 'consumer' is clear and concise.

Dave Longley: I'm completely split down the middle on this.

Adam Lake: Consumer seems too nebulous.

Dave Crocker: The more I think about it, the more I want delegation of inspection as an option, but I think inspector is very intuitive and not as vague as consumer

Carla Casilli: + 1 On inspector, the open badges community uses consumer as organizations / individuals who make use of badges and do not provide gateways to viewing. Recipient is also the holder of an open badge.

Manu Sporny: Recipient has been confused as holder in some cases.

Gregg Kellogg: Note that the glossary defines “credential consumer”: http://opencreds.org/specs/source/glossary/#dfn-credential-consumer

Nate Otto: (Err, I meant prefer "consumer" on my q-plus)

Matt Stone: In favor of the term 'inspector'. Think of someone asking to see your drivers license. They are not consuming it but are in fact inspecting it.

Gregg Kellogg: We do have in our global glossary the term 'credential consumer', but I can accept 'inspector' if necessary

Shane McCarron: Credential consumer

Shane McCarron: An entity that requests a credential for processing.y

Shane McCarron: 'Processor' ?

Dave Longley: "Requestor"

Nate Otto: Ditto. I prefer consumer since a consumer does care about the meaning of the credential.

Kerri Lemoie: +1 Processor

Richard Varn: Claim processor is very much an insurance term

Kerri Lemoie: Agree with Nate on 'consumer'. 'inspector' implies authority, which may not be appropriate.

Manu Sporny: Vote will be between inspector and consumer

Adam Lake: Don't want to confuse the conversation but can't we have both inspector and consumer? They play different roles, no?

Carla Casilli: My concern with 'consumer' is that the general public understands this term differently than they would understand 'inspector'. It is in fact acting as a gateway.

Kerri Lemoie: Adam - thinking similarly

Matt Stone: +1 Inspector

Manu Sporny: This may be a more challenging vote.

Nate Otto: Lost audio?

Dave Crocker: +1 Inspector

Gregg Kellogg: +1 Consumer, +0 inspector

Shane McCarron: Voip 34d is ShaneM

Nate Otto: If there's a current ask, could you ask it in text, having trouble getting back on the audio

Richard Varn: Noun--inspector is descriptive as to the action. verb: consume. the inspector consumes the claim once it passes inspection

David Ezell: +1 For consumer. (It reads similarly to use in the web service space.)

Manu Sporny: We are trying to pick a set of terms just to standardize across docs. we could change that term to something else later, but we need something unified for now as a single term.

PROPOSAL: Choose to use the inspector terminology instead of the consumer terminology.

Brian Sletten: -1

Matt Stone: +1 Inspector

Dave Longley: +0

Les Chasen: +1

Dan Burnett: +1

Manu Sporny: +1

Gregg Kellogg: -0, Prefer consumer

Eric Korb: -1 Inspector

Kerri Lemoie: -1

Nate Otto: -0 Prefer consumer

Carla Casilli: +1 On inspector

Eric Korb: +1 Consumer

Joe Andrieu: +1

Shane McCarron: -0 Prefer consumer too.

Jason Weaver: -1

Richard Varn: +1 Inspector (can use verb consume to describe action of inspector if that helps)

Dave Crocker: +1 Inspector

Dan Burnett: Actually mine is +0

Manu Sporny: 5 For consumer, 8 for inspector, 5 abstentions - we do not have consensus

... will leave as 'consumer' for now because that is the language we have been using

... any concerns with the reading of the vote?

... will standardize all docs on use of 'consumer'. We may have to revisit this.

Topic: Other items

Manu Sporny: Adam is working on primer.

... survey results are still changing. total of 55 orgs.

Carla Casilli: Want to share the definitions of terms that the Connecting Credentials folks have been working on and how this works with the Credentials Transparency Initiative as we move toward defining TBD credential. It's focused on an edu credentials. but might be worthwhile fodder. https://docs.google.com/document/d/1w5oOsGtrYDLq_b4WsAkRCO-XFdH2fsIZmbuUxUY2VVE/edit

Dave Longley: +1 To that note

Joe Andrieu: To answer a couple questions about "subject"... the in some use cases the subject is not the holder, e.g., in cases of birth/death

Matt Stone: Thanks all!

The Verifiable Claims Task Force

A Task Force of the Web Payments Interest Group