W3C Verifiable Claims Working Group -- 27 Jun 2017

<burn> scribenick: nage

Agenda review, Introductions and Reintroductions

<stonematt> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Jun/0015.html

burn: any comments corrections or adjustments to the agenda?
...: is there anyone new on the call?
... nope. Reintroductions, John havev you reintroduced yourself yet?

JohnTib: I'm here representing Vital Source, they are in the education digital assets space
...: my interest in this is from some early work we were doing representing records of performance
... most of my interest is in how do we render such things, and the particular topics I'm interested in are best practices regarding verifiable claims.
... transcripts can be quite large and there is a lot of derivitave data, that in a relational sense would be denormalized out of a data structure
... do you put in both the course name and the description, since the VC asserts the correctness of the record?
... we've worked closely with the national association of registrars on this, and how these questions might be answered
... what types of data should go in, should it be minimal or should it include data that could be mutable
... so that is me

WG Face to Face meeting @ TPAC (see https://www.w3.org/2017/11/TPAC/Overview.html#details)

burn: thank you. Next topic is the F2F meeting
... just a reminder please do register and get your hotel rooms if you can
... some additional rooms may have opened up, Make your reservations soon. Hotel rooms seem to be quite expensive that week.
... any questions about the face to face meeting at this point (we will begin discussing the agenda as we get closer)

Discuss FPWD for Data Model doc--what issues are blocking finalizing the FPWD

PR 56: Report from Manu on terminology list and poll

burn: Manu, please speak first to the status of this, and the next topic will be opportunities for anyone to speak up with insights or conclusions that they have been able to draw so far

<Zakim> manu, you wanted to report back on where we are.

<manu> Terminology Playground Text: https://docs.google.com/document/d/1NWdpFxbERXZodvbJP_GgGZhkGI54zWmqTuFz-CR2hps/edit

manu: we have three things that we're working with. A terminology playground text
... where we have been collecting options that people have been throwing out, to make sure we've gathered all the suggestions.

<manu> Terminology Playground: https://vcwg-terminology-playground.firebaseapp.com/

manu: we also have a terminilogy playground that allows people to select different terms for each sentence and see how they fit in with the types of statements that are being made
... then we have a poll that is setup

<manu> Terminology Poll: https://www.opavote.com/en/vote/5724357032673280?p=1

manu: which is a preview of the poll
... we hope to use these tools to come up with a decision about the terminology and collect as much data as possible about preferences and use that to make a final decision about what language goes into the document
... I think we've collected as much data as we can at this point. We likely need to cull the list for option C.
... when there are more than 5 of 6 selections the preference voting starts to be less effective
... I have a proposal on how we can do that, which we can get to when we start culling the list

stonematt: Is it the expectation and is it required that the full list of options needs to be prioritized?

manu: because of the model it is important that all the items are included. If people stop caring after option 10 than the tiebreaking can lead to the wrong outcome in the poll.

burn: The chairs proposal for where to go next is to ask if others have any insights or conclusions for the terminolgy discussion
... what we are looking for is for anyone who is following the discussion can you point out things that you have learned from the discussion
... if there is something you understand as a distinction that you didn't understand before, please point that out

TallTed: this particular poll, I'm a little concerned that there isn't a way to have a negative vote for something.

<Zakim> manu, you wanted to note negative votes in IRV polling.

TallTed: for example Claimant doesn't make sense at all, and I would like for it to be a non-choice

manu: for role C we'll go through an exercise here in a second that will cut off the bottom ones. Ted you'll effectively have an opportunity to do that here. In general in instant run off voting you don't have negative votes because you don't need them.
... everything put at the bottom of the list generally stay there

TallTed: the playground as it stands does not update the paragraphs.

<JohnTib> it doesn't work on chrome. it works on safari and firefox

ChristopherA: sometimes you have to hit the fields twice to get them to update after a second or two

manu: it is listening to an onclick event without any frameworks, so different versions of different browsers behave differently

<ChristopherA> ?+

burn: any other statements about realizations

<Varn> for the poll, does one have to rank all the terms? can they be just left off?

<manu> nage: The entity that we were calling the "Holder" or "Prover", they don't always have the cryptographic material that's used to sign the information, but they may hold the key - some of the terms that we've thrown around can cause problems around protocol implementations.

<manu> nage: That entity that's in the middle, may receive something, they may give something to someone else - so, we have to be careful with that middle term of the middle person - the thing receiving/presenting, they can be receiving AND presenting... unlike in traditional triangle model, every entity can play multiple roles at the same time.

<manu> nage: So, we have to be careful about what sorts of terminology goes there - depending on the use case, the terminology for the middle person can be very different.

ChristopherA: I had some similar observations last week about things such as holder, like holder of the keys
... which isn't really correct
... my main thing here is an observation that in the playground, the last sentence may be problematic
... I demonstrated how some changes to the last statement effectively mean the same thing
... the "holder" (not sure which word to use) is essentially the subject of the claim
... or perhaps is authorized or allowed to represent the subject of the claim
... basically ends up meaning the same thing as that last sentence
... I see why from a self-soverign point of view, but not sure how it applys to the data model
... I had Relying Party as a term in my mind for the party that is relying on the claim (think of the over 21 example)
... the bartender role, but that entity is not the inspector

burn: please keep this time to observations that were useful to you that might be useful to others as well

dlongley: for role C which is essentially been called holder, folks are chosing terms for thier most common use cases, but we haven't really spanned the term to the most common denominator
... essentiaily party 1 can make a claim to party 2 that they can share with party 3 without involving party 1
... where party 2 can move the place from one place from another

Varn: we are trying to solve our common problem by comming up with a term that is compound with role and task that is tricky to articulate
... that person can be a broker or an agent or the subject that constitutes the top descriptor
... you can be a self-submitter a broker or an agent or an entity

<dlongley> The main strength or feature of Verifiable Claims is that party A can make a claim that party B can share with party C, where: party C doesn't have to trust party B and party A doesn't have to know that party B shared the claim with party C.

Varn: once the person that recieves the claim they may not do all the work that is relevant to what we're talking about, they may sub out soe of the work

<Zakim> manu, you wanted to note that Christopher used Relying Party for the wrong role, and that's why the statement didn't work.

<dlongley> The common denominator is that party B "moves" or "shares" the claim. That's it -- there are often other aspects integral to party B, but those are use case specific.

Varn: I think we'll get to the point where we have reasonable descriptors to solve the problem, but adding some sub roles might help us simplify this discussion

manu: I wanted to do a quick note where ChristopherA mentioned about Relying Party around role C or role D
... if you use it for role C it doesn't work, but I think that isn't what others were suggesting, I think they wanted to add Relying Party to role D
... the confusion around the previous terms remains the same. Whenever we have this discussion we tend to rehash things
... in doing so, we discover new things. In this case revealing Subject as a role makes the things that others have been observing has simplified what others have been talking about for a while.
... if we can get to some common denominator first principles as a foundation, it will help with this role C dillema
... this breakdown on role C is really dependent on the protocol
... and adding subject has made it easier to talk about this common denominator
... we have some folks talking about the common denominator, and other talking about specific use cases, but we have to do both at once
... the first discussion is about how to boil the ecosystem down to atomic parts

<dlongley> Christopher: the "bar tender" or "car dealership" is Role D, so that's why people think relying party is Role D.

<dlongley> "Inspector" may be what is confusing there as its current name.

manu: the second is, in particular scenarios do the terms make sense

<JoeAndrieu> +1 for the need to make a terms decision that is based on the common denominator across all use cases.

TallTed: the more I've been reading on this, the more I'm convinced that the there has been a lot of condensation about multiple actors into a single role
... I can make a claim about myself, but it isn't useful to say that these roles are all one.
... there are multiple roles being filled by the same person, and we don't want to cram too many of them into one single term in all these cases
... when there are more than one role active, we don't necessarily need to boil it down to one term

<dlongley> and there's a danger with selecting too many Roles -- where then it becomes unclear which Role is which; I do think we have found the main purpose for this Role, which is moving a claim from the party that made the claim to the party that relies upon it.

manu: usually we need to get things down to 5 or 6 selections, so what we're going to try to do is get over the rush of new comments that came in at the very end
... for example Signatory, Conveyor and Transmitter
... these are very new additions, and we need to see if folks want them on the poll
... the other thing we need to do is cull role C down
... I will copy and paste something into the channel, for example for role C
... please vote for the 6 items that you definitely want to see on the poll
... everyone should do that, and we won't try to tabulate those results on the call
... shortly after the call I'll sum them up and everything above the water mark (6 items) will go on the poll and everything else will be dropped
... on the other shorter lists we'll simply be looking for any objections to the new terms
... again the purpose is to cull the list not to argue for what you want
... simple up/down vote on each of these items
... if the chairs are okay with it will go through each. Please type out your response on IRC so we have a record of everyone's response
... chairs is that clear enough?

burn: let's go to the queue

TallTed: this seems like putting the cart before the horse as many of these terms are not very clearly defined
... the text on that playground demonstrates that

<Varn> do we have enough members present to do voting on irc?

manu: here is a counter argument: we have been having this discussion for two years now

<burn> varn, yes. we have one of the fullest meetings ever

manu: and we're not making a final decision, but trying to get a draft document out

<amigus> +q

manu: what I've seen in the discussion is that folks have a good grasp on what these roles do and the debate is about what to merge or split apart
... and these terms haven't been modified much
... I agree with you Ted that there are some things that aren't very well defined, but things seem to be functionally defined

TallTed: I've tried to pictorally represent this and have not been able to do so

manu: we do have a diagram that lays this out, I'm not sure if someone can find it. It was used to define the group.
... we have one as well that breaks it into more atomic components

TallTed: what is here right now is simply incomprehensible
... I can make heads or tails going all the way through

<Varn> can sub-roles be added to the model later if determined to be useful?

burn: we have someone else on the queue, please put yourself on the queue to add comments

amigus: just to push back on the current conversation, we're picking these terms based on their definability
... so we can evaluate how well we can define the terms

cwebber: I've been mostly quiet becuase some folks seem more well versed in these terms.

<dlongley> TallTed: http://w3c.github.io/webpayments-ig/VCTF/architecture/

<TallTed> if we're talking about placeholders -- RoleA, RoleB, RoleC, or Alice, Bob, Charlie, would be better

cwebber: we've trying to get good working terms, and I find that argument to be a strong one
... there is a real risk of not moving forward if we try to hit perfection at this point

<JohnTib> Diagram that I've always liked: Figure 2 of http://w3c.github.io/webpayments-ig/VCTF/architecture/detailed/

<dlongley> specifically: http://w3c.github.io/webpayments-ig/VCTF/architecture/architecture.svg

<Zakim> manu, you wanted to ask for a concrete proposal.

cwebber: language is so squishy that it is possible to get stuck in these things forever

manu: I'm congnizant that Ted is bringing up a good point that he has a lot of experience in standards and it isn't making sense, meaning there is more work to do here
... as cwebber said, we're not after perfection, just trying to get to working terms for the draft.
... if there is a better proposal out there, please make that proposal. But also don't make that suggestion off the top of your head.
... we wan't this to end with some finality so that we can move on to the more techincal work

burn: these terminology discussions can go on forever

<TallTed> http://w3c.github.io/webpayments-ig/VCTF/architecture/#basic-architecture shows that there are at least *three* roles under the "Holder" label

burn: and right now I don't care about what terms we use because that isn't the most important
... what is important is that the concepts, meaning the roles that are important are represented there

<ChristopherA> I'm more concerned about the list of phrases. That is why I think the terms are so hard.

burn: the other reason it is important is that there is a group mindshare that is very important
... and we need to be able to communicate it to new folks in the groups

ChristopherA: I have some flexibility for the words, and as a long time standards person I've experienced this before
... but my feeling is that we're still missing some steps and that is killing us
... perhaps a little time splitting up where the confusions are will help
... like someone is "given this data object", but then there are some steps that might need to be divided
... and that might help clarify some things
... I'm also open to deferring that discussion to later, but there seems to be a lot of energy on this right now
... we don't want to have to be bike shedding on this the next time as well

<dlongley> +1 on getting the list more reasonably sized

Varn: remember we had a resolution process to boil this down to a reasonable length list
... then once the poll results are in, we can add a comment to it that it is a place holder that needs more work

<burn> Christopher, we can always put "Role1", "Role2", etc. in the draft. Let's not bikeshed, but let's get the concepts right.

<amigus> \ \\\\\\

Varn: and if there is real strong disagreement we can pull it out for now

<amigus> ]\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Varn: also it is important to remmeber that there are new roles to add that could help solve some of these problems

<amigus> yep, sorry!

Varn: there are tasks that they have to do that can be addressed as we move forward
... once we get to a reasonable list of things to vote on

<amigus> lol, well, maybe a little

Varn: lets see how the poll comes out and see if we are happy with the results and then evaluate what to do next

Joe: process wise thanks to the chairs for the time to have this conversation

<stonematt> +1 thank you JoeAndrieu

Joe: we've really needed to have this conversation and I feel like we have had the conversation

<manu> +1 JoeAndrieu

<dlongley> +1

Joe: I think we should take a vote and move through this process
... one additional bit about realizataions to mention is that we are talking about issuing and verifying and recieving claims

<JohnTib> +1 on proceeding to the vote

Joe: but the terms are credentials claims and profiles and we haven't really moved through that
... we don't really have time to deal with that now, but we do have an issue to do that later

<Zakim> manu, you wanted to note that we're not going to have enough time if we keep going.

<cwebber2> +1 also on proceed to vote

+1 on doing the vote

burn: we acknowledge that Ted has concerns about this process step

<JoeAndrieu> https://github.com/w3c/vc-data-model/issues/46 Add section/language about presentation of claims

burn: because the time on the call is almost up and there is no call next week, we'd like to get the poll done and at our next call we will address those concerns

<manu> ROLE_B: Issuer, Authority, Author, Signatory

manu: I will copy the terms for role B, the only one we don't know if there is support for is Signatory

<JoeAndrieu> +1

<TallTed> +1 Signatory

manu: If you support Signatory please put +1 in the channel

<burn> Also doing the poll because we may gain useful information even if we don't take the results of the poll as gospel

<JohnTib> Role B: -1 on signatory

<ChristopherA> -1

manu: we have two minus ones and it is split, when it is split we typically put it on the poll

<ChristopherA> My objection is that is a cryptographric confusion

<dezell> +1 to manu's resolution

<manu> ROLE_D: Inspector, Evaluator, Verifier, Consumer, Guardian?, Relying Party

-1 on signatory for the cryptographic confusion Christopher mentions

manu: on Role D we have enough support for Inspector Evaluator Verifier and Relying Party
... we haven't heard on consumer or guard

<stonematt> -1 consumer; -1 guard

manu: if you want them on the poll please do a +1

<Charles_Engelke> +1 Consumer, +1 Relying Party

<gkellogg> +1 Relying Party

-1 consumer

<amigus> +1 Relying Party +1 Consumer

<ChristopherA> -1 gard, -1 consumer, very confused relying party as D

<cwebber2> -1 Relying Party

<Varn> -1 guard

<JohnTib> -1 guart

<Charles_Engelke> -1 Guard

<JoeAndrieu> +1 relying party +1 consumer -1 guard

<gkellogg> -1 Guard

<Varn> -1 consumer

manu: I have pasted ROLE_D, please +1 and -1

<ChristopherA> -1 to relying party as D

<gkellogg> +1 Consumer

<TallTed> it's a hybrid Role .... specific labels don't comprise all the roles served

<TallTed> +1 Relying Party, 0 consumer, 0 guard

<JohnTib> concern about RP because I believe it's responsibilities differ from OIDC...but not enough to -1

manu: I will have to go through and tally everything up unless the chairs want to make a call here
... consumer stays on the poll, and guard is off of the poll
... relying party stays on the poll
... any objections to this?

<ChristopherA> +1 to final list

<JoeAndrieu> ChristopherA, I'm with dlongley. Role D is the bartender. This role is not just the cryptographic verification, but the party who will apply the statement once verified

manu: (if you disagree with the reading of the votes on IRC)

<stonematt> propose: ROLE_D: Inspector, Evaluator, Verifier, Consumer, Relying Party

manu: role C we will do differently
... We're going through the same exercise specifically for the new terms from the last 24 hours

<manu> ROLE_C: Do we want to add: Conveyor, Transmitter, Asserter

manu: I'm going to put three choices in here

<Varn> +1 asserter

<ChristopherA> Joe & Longly — then to make that work that make it high on my list to rewrite the phrases in the playground.

<Charles_Engelke> +1 Conveyer

<JoeAndrieu> -1 conveyer

-1 Conveyor -1 Transmitter

<dlongley> +1 conveyor

<TallTed> +1 Asserter, 0 Conveyor, 0 Transmitter

<ChristopherA> -1 conveyor -1 transmistter

<Charles_Engelke> -1 transmitter

<JohnTib> -1 conveyor, -1 transmitter

<dlongley> -1 transmitter

<stonematt> -1 on Conveyor -1 Transmitter

<amigus> -1 Conveyor -1 transmitter

<ChristopherA> worried about asserter but ok

manu: transmitter is being removed

<Varn> -1 conveyer

<gkellogg> -1 Conveyer

<Varn> -1 transmitter

<JoeAndrieu> -1 Asserter

manu: conveyor is 2 votes in favor 7 votes against

<dlongley> -1 asserter

manu: conveyor and transmitter are being removed

<ChristopherA> -1/2 for asserter

<ChristopherA> ;-)

-1 Asserter

<amigus> +1 asserter

manu: asserter is staying because it is split, does anyone object?

<ChristopherA> (I have to run to host other meeting.)

manu: good. Now here is the final thing to collect. Here are all the choices for Role C, with the two removed already removed
... only copy and paste the l ilst of items you'd like to see on the poll, you get 6 votes

<manu> ROLE_C: Holder, Presenter, Receiver, Claimant, Subject, Prover, Guardian, Mediator, Subject(‘s) Agent, Owner, Sharer, Recipient, Asserter

manu: only pick the six items that you would like to see on the poll, do "role C: <your six>"

<TallTed> RoleC is *major* hybrid.

<JohnTib> ROLE C: Holder, Presenter, Receiver, Asserter, Claimant

<ChristopherA> Role C: Holder, Presenter, Claimant, Prover, Subject(‘s) Agent, Recipient

<cwebber2> ROLE_C: Holder, Presenter, Receiver, Sharer, Recipient, Asserter

<ChristopherA> bye!

ROLE_C: Holder, Claimant, Prover, Subject(‘s) Agent

<gkellogg> ROLE_C Holder, Presenter, Claimant, Guardian, Subject(‘s) Agent, Asserter

<dlongley> ROLE_C: Holder, Presenter, Subject, Subject's Agent, Mediator, Sharer

<Varn> Holder, Presenter, Mediator, Subject(‘s) Agent, , Sharer, , Asserter

<Colleen> Role_C: Holder, Presenter, Receiver, Mediator, Asserter, Sharer

<amigus> ROLE_C: Holder, Presenter, Subject, Owner, Asserter

<stonematt> ROLE_C: Holder, Presenter, Subject, Prover, Guardian, Sharer

<JoeAndrieu> Role C: Presenter, Claimant, Owner, Sharer, Asserter

<Charles_Engelke> Role C: Holder, Presenter, Claimant, Prover, Sharer, Asserter

manu: while folks are finishing up here, I can tally all the votes, and then pass a suggested resolution by the chairs, and if they agree to that we will send that out to the mailing list
... if there are no strong objections by the end of the day today we can start the poll

<TallTed> +1 Holder, Presenter, Claimant, Mediator, (not necessarily Subject's!) Agent, Asserter

<stonematt> +1 on process

burn: that is fine
... anything else manu?

<cwebber2> +1 on process also

manu: that is all we need to run the poll thank you

<JoeAndrieu> +1 process. Thanks.

burn: if you've given your information here, feel free to go.
... no call next week
... we'll see you in two weeks

<dlongley> to reiterate my position on how these roles may be best simply defined: Someone makes a claim, someone relies upon it, and someone decides to share it between those two parties.

- DRAFT -

W3C Verifiable Claims Working Group

27 Jun 2017

Attendees

Contents

Agenda review, Introductions and Reintroductions

WG Face to Face meeting @ TPAC (see https://www.w3.org/2017/11/TPAC/Overview.html#details)

Discuss FPWD for Data Model doc--what issues are blocking finalizing the FPWD

PR 56: Report from Manu on terminology list and poll

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output