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

Verifiable Claims Telecon Minutes for 2016-06-07

From: <msporny@digitalbazaar.com>
Date: Tue, 07 Jun 2016 13:45:08 -0400
Message-Id: <1465321508464.0.14229@zoe>
To: Web Payments IG <public-webpayments-ig@w3.org>, Credentials CG <public-credentials@w3.org>
Thanks to Dan Burnett 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-07

  1. VCTF Deliverables
  2. Verifiable Claims Use Cases Review
  3. Verifiable Claims Charter
  4. Verifiable Claims Charter FAQ
  5. Architecture Summary
  6. Verifiable Claims Data Model Specification
  7. Terminology Conflicts
  8. Other items
  1. Adopt self-sovereign terminology over user-centric 
  Manu Sporny
  Dan Burnett and Manu Sporny
  Dan Burnett, Manu Sporny, Joe Kaplan, Nate Otto, Matt Stone, 
  Shane McCarron, Dave Longley, Adam Lake, Dave Crocker, Joe 
  Andrieu, Gregg Kellogg, David Ezell, Kerri Lemoie, Eric Korb, 
  Richard Varn, Les Chasen, Jason Weaver, Brian Sletten, Carla 
  Casilli, Rob Trainer, David I. Lehn

Dan Burnett is scribing.
Manu Sporny:   Have to get our deliverables into review shape 
  within 2 weeks for the payments IG
  ... everyone please be brief with your comments so we can get 
  through our full agenda
Dan Burnett:  One quick thing, we need to decide what "TBD" means 
  in "TBD Credential" [scribe assist by Manu Sporny]

Topic: VCTF Deliverables

Manu Sporny: http://w3c.github.io/webpayments-ig/VCTF/
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 
Manu Sporny: This is the document that Joe is talking about - the 
  review he did: 
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 
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: 
Shane McCarron: Note that the wiki should be updated too...  
  ... 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: 
  ... 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 
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 
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 
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 
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 
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 
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 

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 

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" 
  ... 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 
Gregg Kellogg: Note that the glossary defines “credential 
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 
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 
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 

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. 
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!
Received on Tuesday, 7 June 2016 17:45:33 UTC

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