varn: introductions to start

<stonematt> zakim pick a victim

<stonematt> Scribe: JoeAndrieu

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

Introductions and Re-Introductions

Greg Kellogg: Introducing self.

: Works with Spec-Ops. Also RDF-A, JSON-LD and other things

Face to Face in November at TPAC

Face to Face in November at TPAC

<ChristopherA> Reg is now open

varn: Get a room asap or expect to pay more.

<ChristopherA> With IRCcloud you are always logged in.

david: tried to get a room, but there were none for Friday. You might try leaving a day or two off at either end. If you try for the whole week, you're likely to find no rooms available

<Zakim> liam, you wanted to note more rooms may be available next week

liam: They have requested extra rooms, which should become available in the next week or two, at a slightly higher price

varn: FPWD data model

FPWD Data Model Discussion

varn: topic 56 hottest topic

FPWD Data Model Discussion - terminology in PR 56

varn: it's been run out over as many as 60 messages and has become hard to follow what is controversy and consensus
... we want to put together a summary of the points of contention
... in our FPWD we can note the terms that may be challenging. Alternatively, we can remove those terms that are too controversial.
... asking interesting parties to summaries what the main issues are
... if there are camps or advocacy groups, please identify (to help clarify things)

stonematt: doesn't seem we're too far apart. started with issuer (creates claims and give them to holder), the holder, and the inspector who is the party who wants to verify the claim is from the issuer

by and large, issuer and presenter is mostly considetent. "holder" is a different issue

scribe: by and large, issuer and presenter is mostly considetent. "holder" is a different issue

<Zakim> manu, you wanted to propose a couple of specific tried-and-true ways forward and hear from JoeAndrieu.

scribe: maybe we can focus attention on "holder" instead of issuer/inspector

manu: +1 to stonematt's comments

<nage> Sovrin developers have had this debate many times, and the crypto folks there have been calling this entity the "prover" while the others have continued to call it the "holder". The "user" term implies the wrong things, and we have not moved in that direction.

manu: good news is as we were engaging, there was good alignment about what the roles actually do, even while the names might be in dispute
... one problem is that the conversation is currently led by the vocal parties. we're missing the quite voices.
... we need to hear from the people that are silence
... one challenge is whether or not those voices understand the issues deeply before we call for consensus

<manu> Website for trying terminology out in our definitions: https://vcwg-terminology-poll.firebaseapp.com/

manu: this poll has three drop downs, one for each of the three terms we've discussed
... so for people new to the terminology, it will help them understand how the terminology would look in prose
... the poll will use rank-choice to order pollees opinions
... that's manu's polling proposal
... would like to hear from Joe Andrieu and others
... note the current tool isn't the voting mechanism. just the prose generator to help people read the terms in context

<TallTed> Repository seems to be a Holder?

varn: is the presenter an agent

manu: it's all of those things

<nage> you could consider the middle entity the agent in the epistemic sense (whether it is the subject or some entity acting on behalf of the subject). This is why we have been calling it the prover, becuase they may or may not be holding the claims used to issue these proofs.

<nage> but it is correct to say that they have access to them

<nage> to construct the proof

<manu> JoeAndrieu: I like this approach a lot, I think Matt's summary is mostly right. Part of where this went wrong for me, the terms rang wrong... My off the cuff interpretation of that was not accurate. Most of the use cases, like ID2020 use case, those individuals don't have wherewithall to hold anything. I don't think someone else is the agent, you can solve it by having claims in the cloud - in distributed sense - distributed ledger, IPFS, etc. That felt confusing

<manu> to me.

<manu> JoeAndrieu: I think the polling mechanism gives us an opprotunity to talk about it. I wanted to have this conversation, we are having the conversation. This addresses my concerns about process.

dlongley: perhaps we are trying to explain to much too soon, e.g. a verifier and a inspector, subject and holder, etc.

<stonematt> +1 on keep is simple and add nuance later

dlongley: issue claim, about someone, presented to someone else
... moving claims, storing claims, etc. may be extra and unnecessary to the core
... so maybe "subject" is the core to a solution

TallTed: note the subject is not mentioned after the statement becomes a claim
... in other conversations, describing things in a physical sense can make the things simplify.
... we can complexify later if useful, but starting with the physical starts simple

TallTed: the holder of the keys gives the right to control

<Zakim> liam, you wanted to observe people are viewing the roles differently (e.g. is "holder"/"Claimant" a human, software, a proxy, a third party?) and the terms might need to be

liam: from the outside, when people don't agree, often the reason is they are looking at it from different perspectives and not realize it
... maybe what we need are phrases
... that show in more detail what is specifically going on.

<varn> I like modifiers to nouns to distinguish special aspects or use case variables

<dlongley> issuer of a claim, the subject of a claim, evaluator of a claim

<TallTed> ClaimMaker, ClaimSubject, ClaimQuestioner, ClaimDocument ?

<Zakim> manu, you wanted to note clarifying phrases are here (and will be added to): https://vcwg-terminology-poll.firebaseapp.com/

liam: manu: I don't think anyone would oppose issues, subjects, evaluator
... subject may be the least offensive

<varn> ]q+

<TallTed> (middle `Holder` menu doesn't include `Subject`...)

liam: the trick is bringing voices up to speed on the concerns and possibilities of the different terms

<dlongley> note that that website doesn't have an option to replace "Presenter/Holder/Etc" with Subject

<Zakim> JoeAndrieu, you wanted to talk about limits of subject without holder/presenter/claimant

<nage> the idea of subject gets very complicated, as you have to address what entities get identifiers in the system (do you issue a claim to the car, or to the cars owner? who is the proper subject? Ultimately both ways need to work.)

<manu> JoeAndrieu: The suggestion that we don't need the term Holder sounds pretty provocative. We have lots of use cases where presenter is not the subject, and because we're not solving the protocol issues, and we have the data schema, that is a dominant situation. This is at the core of privacy/delegation issues.

<TallTed> ClaimMaker, ClaimSubject, ClaimDocument, ClaimPresenter, ClaimQuestioner

<manu> JoeAndrieu: I like the push I'm hearing toward simplifying - maybe moving/storing claims are not key to the data model, but understanding person who is manipulating is not the Subject is important.

<manu> Varn: Having three generic phrases, A, B, C - none of those words are going to satisfy everyone. You need a secondary data model component that has a modifier that attaches to it.

varn: having three generic phrases, Issuer, Holder, Inspector. Aren't going to address all use cases
... you could have modifiers or categories

<manu> Varn: Categories of issuers, categories of subjects, qualities are going to vary significantly.

varn: universities may be one type of issuer
... evidence shown may vary

<manu> Varn: Phrases are more useful in explaining what we mean by something - put those three units together with modifiers, how these things are supposed to function - these phrases, with these modifiers come together.

<stonematt> we have to be careful about asserting qualitative characteristics about the actors

<varn> noted

<varn> but level of quality according to a spec is common

TallTed: now five terms: claim maker,bclaim subject, claim document, claim presenter, claim questioner

<varn> for example, verified to what level?

TallTed: ClaimMaker, ClaimSubject, ClaimDocument, ClaimPresenter, ClaimQuestioner
... the holder is not necessarily the subject nor the presenter

gkellogg: I like Ted's separation between the subject and the agent presenting that claim to a verifier/inspector

<stonematt> varn you've moving into the a discussion about the rigor that's required to satisfy the inspector for the claim or benefit at hand. The datamodel shouldn't care

gkellogg: that has been confusing. That is definitely the case sometimes; the separation is quite useful

<Zakim> nage, you wanted to mention the concept of claims vs proofs

nage: some of the protocols introduce the concept of a claim v the ability to prove the content of the claim without divulging the claim itself
... would like to separate the claim from the proof so that proofs can be presented without divulging the claim as issued

<varn> i suggest we add ClaimSeeker at some time to identify those who are looking for ClaimSubjects with specific characteristics

<Zakim> manu, you wanted to ask if we've talked this to death and we can start moving toward a set of phrases + ranked choice vote.

manu: I think we've talked this to death
... as an editor of the document, I have no idea what to write. can we start moving towards a numerical driven consensus vetting?

<gkellogg> +1 to creating ranked-choice poll

manu: +1 to poll

<cwebber2> +1 to getting data and moving forward :)

<stonematt> +1 for polling soon.

<dlongley> the name for that is entity profile (currently)

<nage> yes, composite proofs, where you prove that multiple claims were issued to the same ______

<ChristopherA> The presentation has lots of crypto involved

<nage> err....subject

<dlongley> and it's in the spec

<dlongley> the name for combining claims into a single doc about an entity is an "entity profile" and it's in the doc.

<stonematt> +1 to clarifying what a claim is in this ecosystem and all the ways it might be interpreted and used

christopherA: similar thought to Joe's. Different kinds of claims (bearer claims). There are lots of different things that can go on during presentation of a claim. Proof of control. Proof of right to present. All of these are out of scope of just the data model.

<nage> +1 that it is very difficult to talk about some of the important terminology distinctions without any sense of a protocol

varn: summary: manu will get the polling tool working so people can see the terms in context.
... we want to ask the poll not to decide the matter, but to provide data to the editors for capturing the diverse perspectives of the working group

dlongley: quick agreement with ChristopherA: different protocols will use these claims differently.
... so lets keep to the simplest model

<stonematt> on mute...

dlongley: also, "entity profile" is the combination of claims presented to an inspector

stonematt: this is data model oriented language (not protocol oriented). If there's a way in the polling tool to scope the discussion around that focus area, so people can avoid the use cases driven distinctions

manu: will coordinate with the loudest voices to distill a decent polling tool

<varn> to manu--will you consider the compound terms discussed today?

manu: then next week we'll have a chat. one last chance to pipe up. then a week long poll
... and a final decision by the editors follows

varn: will we include compound terms?

manu: if you want them, make a case and rally support

varn: next topic: batting order of upcoming issues

Upcoming Issues

<TallTed> Compound terms are VERY useful when crossing disciplinary boundaries. If people who aren't fully versed in this group use one of our non-compound term in their own discipline, with conflicting meaning, there will be problems.

Richard, is there a link?

varn: issue 9 and issue 35

<stonematt> https://github.com/w3c/vc-data-model/issues/9 and https://github.com/w3c/vc-data-model/issues/35

varn: if you have an item you'd like to see addressed, open an issue.

<manu> TallTed, agreed - but the compound part can depend heavily on the protocol... and if we use the same word, like 'claim' for each compound term, then its usefulness is diminished.

<stonematt> composable and decomposable artifacts?

<manu> JoeAndrieu: How a claim or a set of claims (a credential) are issued from an issuer, and gets sliced/diced into something for evaluator, we need to figure that out - we don't talk about entity profiles in that context - terms in previous things should be 'claimant' delivers 'entity profile' to inspector.

joe: will take the task to add that as an issue

varn: that's what we ask. either comment on 9 or 35 or add your own issue

<manu> JoeAndrieu: Verifiable Claims came up at ID2020 - there was explicit interest in coordinating and having a liason. I'm point person on that for the moment.

<stonematt> +1 for JoeAndrieu to liase w/ ID2020 :)

<stonematt> bye all.

varn: adjourned and thanks

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/thanks//
Succeeded: s/thanks, manu//
Succeeded: s/depends/can depend/
Present: Charles_Engelke Chris_Webber David_Ezell David_Longley Gregg_Kellogg Joe_Andrieu Manu_Sporny Matt_Stone Richard_Varn Christopher_Allen Ted_Thibodeau Liam_Quin Nathan_George
Regrets: Dan_Burnett
Found Scribe: JoeAndrieu
Inferring ScribeNick: JoeAndrieu
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2017Jun/0011.html
Got date from IRC log name: 20 Jun 2017
Guessing minutes URL: http://www.w3.org/2017/06/20-vcwg-minutes.html
People with action items: