Verifiable Claims Working Group -- 16 Jan 2018

<scribe> scribenick: bigbluehat

<dlongley> scribe: bigbluehat

Review the Agenda

Agenda review, Introductions, Re-introductions

Vote on potential spring meeting dates--Monday March 5 or Friday April 6

<burn> See https://docs.google.com/spreadsheets/d/19Ndqc5pLsTu2ZmP4Wy7OlMOmskQFHPh28sMjW3ugsww/edit#gid=0

varn: right now, Rebooting Web of Trust looks best
... it's out West. Santa Barbara
... the other is the IIW meeting...selected a Friday there
... that would be in April
... so. what's our preference?

JoeAndrieu_: so I'm producing Rebooting Web of Trust
... the problem is Monday is a disc golf tournament for RWoT

varn: well. we wouldn't want to conflict with that! ^_^

JoeAndrieu_: so...that's a conflict
... we've got a sponsor

aside--spreadsheet with full list of venues and voting https://docs.google.com/spreadsheets/d/19Ndqc5pLsTu2ZmP4Wy7OlMOmskQFHPh28sMjW3ugsww/edit#gid=0

varn: any other comments for RWoT

manu: let's not mess with disc golf--'cause I want to go too
... Monday with the IIW event might be best
... going back there would be a good thing
... plus it gives us time to plan
... I don't feel like we're making quick enough progress to have enough to talk about as soon as RWoT
... but by IIW we'd have more, and many of us will be there
... I feel like we'll have the specs in a good place by then
... and we can speak with more certainty about that then
... so I'm feeling pretty strongly about IIW

varn: k. any other comments?

Adrian Gropper: so. IIW ends in the early to mid-afternoon. I'd love to get as many of them involved as possible, and I'm concerned with overlap

varn: not sure that's a problem

burn: we don't have Matt here to find his availability, but we had confirmed he could be there

Adrian Gropper: just to clarify, I'd like *more* overlap, not less

<kimhd_> voip: connections?

manu: we'd be more like a long-running breakout session at IIW

<agropper> +1 to late Wed and early Thursday

manu: beginning thursday, we'd launch right into the face to face parts
... the suggestion would be, let's do later part of Wednesday and early Thurs for the F2F meeting

<nage> We've found that overlap with IIW introduces many conflicts for those who are conducting other sessions at IIW (DIF has tried to hold meetings during regular IIW days, and it has caused issues, the way we did the last F2F at IIW on Friday worked well)

varn: k. we'll run that by Matt, but we'll take that as the proposal

<ChristopherA> That crosses over how many days of IIW?

manu: noting what nage said in IRC, there's a good bit of overlap

burn: I think this is related, but I think it's important we connect with others
... and also make sure we provide time for our group to work on items for our group
... if we're able to do updates for new people, and also give ourselves a day for actual work
... I don't care which specific days, personally, but I don't want to drop our working group productivity time

nage: that was essentially my comment
... if we have too much overlap, then we loose people to business networking, and other discussions
... which makes planning the schedule hard
... too many competing interests prevents our focused productive time
... but if we structure it right, we can do both presentations and productive time

ChristopherA: I'm challenged with the W/Th schedule
... because I too have other things to do on W/Th at IIW

<Zakim> JoeAndrieu_, you wanted to discuss distractions with more overlap

<burn> present

ChristopherA: so I'm uncomfortable with that much crossover

JoeAndrieu_: but one thing that IIW does encourage, is wandering in and out of sessions
... so I do like the overlap, but I do think a dedicated day on Friday would help our productivity

<varn> Thurs PM start plus full Friday

varn: k. so I'm hearing consensus around Th + full day Friday

<nage> +1

<burn> +1

<gkellogg> +1

<JoeAndrieu_> +1

<ChristopherA> +1

<manu> +1

PROPOSAL: Thurs PM start plus full Friday

<varn> +1

<tzviya> 0 (I will not be able to attend)

0 (won't be there, afaik)

<agropper> +1

<cwebber2> +1

<ChristopherA> They charge for it. We once Wifi'ed to Google next door to do it.

varn: k. next item...

Volunteer assignments on subject != holder chart review

<burn> Chart link: https://lists.w3.org/Archives/Public/public-vc-wg/2018Jan/att-0006/SubjectHolder.jpg

burn: this is the updated Subject/Holder Relationships in VCs chart

varn: is this the newest one?

burn: yes. that's it

varn: so. let's review this and make sure that this is accurate to what the issues are
... and address them to some degree as to if this is accurate to subject vs. holder
... is that correct burn?

burn: yes. we want to be sure the Data Model reflects these differences
... either to review the entire document, or just part of it
... but we want folks to step up and name themselves in this review

varn: to that end, do we have folks interest in volunteering to do this review?

<manu> I'm under heavy workload... will need to review it eventually, but can't volunteer at this time.

DavidC: I'm willing to do some of this

<burn> would be nice to have at least one more

varn: anyone else have time?
... I'd say this review would need to be done within 2-3 weeks at the most.

DavidC: that's fine for me.

burn: there were several people who'd expressed interest in this topic, and I just want to be sure that those people are either OK with DavidC doing the review or are able to actively participate in the review

manu: yeah. I agree.
... if we don't have enough review, we are endanger of that
... it's a problem we have as a WG at this point
... we're not getting enough volunteers, so we're not making enough progress
... but without those volunteers, we can't progress

varn: I'll take that to heart
... the middle of this wish-bone chart here. I'll take a look at a couple of these

burn: and just so you know, I have a personal beer fund for things like this

varn: we have two, but if we don't get enough review, we'll have to assign folks

nage: there's one question we might have discussed briefly
... when we have more than one potential subject in the credential--and it's not clear who the holder is
... that one's not in the chart

varn: yeah. it's not in there, but I think it needs to be

<tzviya> I can help with reviews in Feb when I have a little less on my TODO list

<burn> Thanks Tzviya

DavidC: yeah. I thought about that. You could say it is in the chart, but it doesn't clarify how many subjects are in the credential
... for the other subject that's in the credential, it would be some of the decision points going down the right-hand side
... so, in one case the subject would equal the holder, and in the other it would equal the subject
... in the medical record case, isn't the doctor the issuer?

nage: in the F2F, the monitoring machinery was the issuer
... and it was giving that data about more than one subject

DavidC: so the issuer essentially doesn't act for any of those subjects
... and the doctor who's holding it doesn't match any of those criteria

nage: I was wondering if we needed a step before the chart starts
... something like "unambiguously clarify that the subject = holder"
... I'd like to find a better example than the medical record one
... perhaps the recruiter example

DavidC: the fact that the subject is a set of IDs--or someone way of pointing at the subject
... we haven't yet gotten to how to clarify who's giving the credential to me
... and if it's not the subject, who is it
... and perhaps its not in the model, but in the protocol

nage: that does get to the situations I was hoping to highlight--where this data lives in or out of the data graph
... as long as we have enough understanding to move the conversation forward, then I'm content

varn: that made my head hurt. It's tricky to see who's acting for who in what way

<Zakim> manu, you wanted to wonder if that is a signal that we should think of - ambiguous semantics. and to say that we're leaning away from multi-subject credentials.

varn: any other feedback?

manu: yes. I'd like to respond to the issue raised
... nage we do need to discuss this in more depth
... I think we're talking past each other a bit
... multi-subject credentials
... credentials that could be issues to multi-subjects at the same time
... right now the data model is shying away from that
... so right now, you'd issue separate credentials per subject
... you'd issue maybe 1k credentials--one per subject

<dlongley> the credential "triple" is: <credential_id> <claim> <subject>

manu: the reason we're taking that approach is that it's a far simpler data model to reason about

<dlongley> we only make claims about one subject

manu: if you have multiple subjects, you issue a separate credential to each one
... I know this has privacy ramifications

<dlongley> that doesn't mean that the model doens't include all kinds of (potentially) other relationships between the subject and other entities.

manu: but we do have multiple ways of dealing with this
... but since we're still talking in abstract terms, I think we need to try and push for a specific use case first
... so we can talk about how the data model and the protocol fits together
... to clarify what exactly we're trying to achieve

<nage> manu: but you do have to set _something_, can you use signature property in such a case to keep the subject clearly enumerated?

manu: once we have that, we'll be able to make more progress

<Zakim> burn, you wanted to ask whether multi-subject could be handled via a separate credential that links multiple subjects

<nage> (that is what attribute based credentials do)

burn: this is a question about something manu said

<dlongley> but there's just one "claim" relationship between the credential and the "subject" -- that keeps it simple.

<manu> nage, you can sign something that doesn't have a subject.

burn: is there anyway to issue that ties together several subjects?
... and then issue a credential for that?

<nage> yes but from a data graph perspective the relationship still has be be explicit to avoid abuse

burn: rather than issuing a credential for each one

manu: yeah. you'd use something like a group id
... and then issue a credential for that

<dlongley> the relationship is explicit w/o labeling the subject

burn: yeah. that

<Zakim> JoeAndrieu_, you wanted to point out where marriage license is in the chart

manu: but I'm not sure that handle's nage's use case
... because it's not clear to me

JoeAndrieu_: the problem is that the group id externalizes what's verified

<manu> nage, yes -- that's true, I think... but we really need to understand the desired use case and security model to really get at the heart of this.

<dlongley> i.e. "there exists 'some entity' with these attributes" vs. "*this* entity has these attributes"

JoeAndrieu_: looking at this I think the marriage license captures the most coherent version of this
... because subject is singular

<nage> manu: agreed

JoeAndrieu_: perhaps DavidC could number the chart
... so the second one, on the left side...the "irrelevant who holder is"
... in the case of the marriage license, it's going to uniquely want to get married
... but it's irrelevant who the holder is
... and hopefully handles what you were looking for DavidC

DavidC: I did like the first discussion about group id

<manu> nage, to put it a different way, I think there are multiple ways to do this with the current data model, but I'm concerned that we're missing something wrt. CL Signatures (there is something provided by CL Signatures that may make this easier, but it's not possible to express that in the data model)

DavidC: that you would group the subjects, and then provide the credential for that group
... I don't think there's a problem with different issuers reusing the same group id
... because all the IDs will be uniquely assigned
... but when we come to a marriage certificate, I'm not sure group id is applicable
... so I'm not sure how the current data model would fit with that scenario
... maybe they get a "married name" group id, and then the credentials get applied to that

<nage> it is fundamentally a credential binding problem, which "identifier" do we bind the credential to, and how do we make sure that in the case of an ambiguity it is clear which entity we used to bind *this* credential

DavidC: and then make other claims about each subject that backs up that group claim

<dlongley> two credentials: {<credential_id_1> <claim> <spouse1>, <spouse1> <married> <spouse2>} ... {<credential_id_2> <claim> <spouse2>, <spouse2> <married> <spouse1>}

varn: having been through a couple divorces, sometimes you have to make assertions with your credential--outside of the group id
... the other is a HIPAA case

<TallTed> marriage is a (not very) special-case of partnership

varn: to assert something wrt to money or a need to assert something
... for instance, I need to sign something to verify the doctor can submit something on my behalf

<burn> agree, TallTed. In most partnerships there is a way for one to pull out unilaterally

varn: it'd also be great to get representation from that community

<DavidC> I cannot hear any of this

<JoeAndrieu_> LOL. Adrian is a doctor. Willing to help with use case

Adrian Gropper: I'm happy to work on this use case as a HIPPA expert

varn: k. next topic

CG alignment/Coordination Update--DID Method Registry

UNKNOWN_SPEAKER: there are 3 total ways we might work together
... the DID Method, Linked Data Key Types, and Credential Status Method Registry

<Zakim> manu, you wanted to report on these items.

CG alignment/Coordination Update

manu: the good news is that all 3 registries have been created and populated with initial content

<manu> DID Method Registry is here https://w3c-ccg.github.io/did-method-registry/

<manu> Verifiable Credentials Status Registry here https://w3c-ccg.github.io/vc-status-registry/

<manu> Linked Data Key Formats Registry is here https://w3c-ccg.github.io/ld-key-registry/

manu: all the registries are created and setup
... all we plan to do from hear out is updating them

<manu> The announcement for the registries was made here: https://lists.w3.org/Archives/Public/public-credentials/2018Jan/0050.html

manu: this clears us to work on revocation
... we can start working on a revocation spec
... the first is a simple list-based URL
... the other could be a blockchain-based registry
... that was one of the things in the Verifiable Claims spec that needed clarifying
... I hope to also add a HTTP Status spec
... and to begin handling the revocation actions
... and the other is a verifiable profile example
... those seem to be the 2 remaining items for the spec
... we may have more pop out as part of this subject != holder discussion
... but that's it for now

varn: thank you manu. anyone else have thoughts?
... what are the next steps?

manu: we need to work on status checking and revocation
... if someone wants to pick that up, that'd be great
... if no one else does, I'll have to...because we need it

JoeAndrieu_: so we're working on a work breakdown structure for what we're hoping to accomplish
... and forward that to the VCWG
... our mental model was what are CG outputs that might go into other WG's
... but it's not a relay race
... I don't have any concreate proposals, but perhaps a follow-up chairs call

<burn> +1 to CCG/VCWG chair discussion

varn: any volunteers to write this spec?
... we'll see about the chair's discussion
... we'll review this further on the chair's call on Friday
... anything else to add anyone?

Domain Discussion of the Week (Use Cases)

varn: JoeAndrieu_, you're up. you've got about 10 minutes

<JoeAndrieu_> https://docs.google.com/spreadsheets/d/1sUt7OPv5B_DWa4SQcOl16ZZqLg2URwNPmsEhCrisvxM/edit?usp=sharing

varn: if you need all that time, we'll skip the last two planned agenda items

JoeAndrieu_: so. personally life's been crazy--my town is on fire and sliding into the ocean
... so, 38, 39, & 40 are the topics for today
... BC1. Viral coupons
... BC2. First come, first served offers
... BC3. One-time Passwords
... we currently only have the title
... we need more than that--if you look in the other labeled sheets
... BC1. I want anyone in the world to get this
... BC2. is a gold ticket--it's a single use, but anyone can have/find it
... BC3. is a one-time password. a verifiable credential could wrap that, but it's ephemeral on time and use
... once you use it you can't use it again
... the process here is
... you add your name + what you think about it
... you can see the example with my (JoeAndrieu_) name on it
... so BC1. it's a viral coupon
... manu just added his 4 values, and added a note--that he loves the digital coupons idea
... this is the basic framework for this section
... my goal is that this would be added and sent out before the meeting

<Zakim> manu, you wanted to mention concert tickets or stadium tickets. and to note that viral coupons are actually controlled... wonders if dezell can say anything about it.

JoeAndrieu_: in the future, hopefully we'll have more time to do that

manu: some input on the use cases
... I don't see concert tickets or stadium tickets on here
... I think they're essentially bearer tokens, aren't they?
... don't think they have names on them
... if we had to swap one out, I'd bring that one in

<varn> yes, i think they are bearer tokens that are only related to holder in some back end non-credential system

manu: the first-come-first-served thing is also pretty similar to the virtual coupon
... but, we may also want to break all these out into various use cases
... if we do head down that route, we'd have good chats with the Web Commerce CG
... and we've got points of contacts we can connect here
... there are things like FIDO and U2F and also One Time Password stuff happening there
... we might do best to piggy back on that
... it might help to show people how to make a VC that can do that
... but it might be best to show how to use it with the Web Auth group

<JoeAndrieu_> I added BC4 Concert Ticket

DavidC: Concert Tickets feel like a one-time use token
... the only slight different is the date being specified

varn: we'll have an additional discussions, but bye for now

- DRAFT -

Verifiable Claims Working Group

16 Jan 2018

Attendees

Contents