Verifiable Claims Working Group -- 24 Apr 2018

<burn> s/Present: Dan

I could scribe

<scribe> scribenick: cwebber2

burn: let's go ahead and get started

Agenda review, Introductions, Re-introductions (5 min)

burn: agenda today, we're going to review action item list, then after we do that we'll assign owners to unassigned issues in github
... primary goal today is a focal use case
... suggestions to modifications to the agenda?
... I don't think we have anyone new on the call?
... is there anyone new on that I missed somehow?
... once we get a few people to join I think we can restart the introduction process again
... next topic is action item review

Action Item Review

burn: for that we have a link

<burn> https://goo.gl/V4XTBT

<stonematt> Running Actions Items (w/out goo.gl): https://docs.google.com/spreadsheets/d/1XIRn3VltrK_Dxqz0VyDxPi265sW47EMSKVKUXmMkI70/edit#gid=0

burn: the chairs have been using the google shortener, but only for google documents
... we also learned that the google link shortener is apparently going away not too far from now
... terms of use...

stonematt I think we're covering this during the focal use case today

DavidC: I added that to the ToU as examples

stonematt: I think we should mark this as closed, we're tracking this elsewhere

burn: btw that's the intent, these are things people have agreed to do but the goal is to move things to github

agropper: I just dialed in

burn: I don't think we have manu on the call so we'll skip his

stonematt: (line 28) inherited this from the F2F, there's some discussion about what the id in json-ld means, and about running issues in 125, don't think it's the same but may be related to 120
... should we have 120 resolve it
... this is really about the implied functionality in json-ld
... christopher allen also expressed discomfort with the role of the id
... is this also an issue w/ issue 120 or do we need to open another issue about it?
... not sure if Christopher Allen is present today

burn: he's gone today

DavidC: maybe I should look at it... that's because I was confused as to what id refers to, but now I understand json-ld better. I unerstand the id is the id of the object
... and the next thing is the type which is the type of the object
... I think that's ok, but we're still inconsistent in some areas
... we have some inconsistency in how we're using id eg in termsOfUse

<Identitwyoman> Hi I just joined.

stonematt: can we close and drop this from action items?

burn: let's do that for now, if we need to move it to its own issue later we can do that
... this one is row 30
... on cwebber2 and nage and how to connect on the test suite

<burn> cwebber: nathan and I still need to talk. got an overview from manu on previous conversations , but still need to do this.

cwebber2: I talked with manu about previous conversations with nage but I still need to talk to nage

burn: I think that's it for items for people who are here
... who dialed in?

Identitwyoman: hello, I announced myself on irc

burn: ah sometimes it's hard to tell from reading irc
... onto the next item, assign owners to unassigned issues

Assign owners to unassigned issues

<burn> https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+no%3Aassignee

burn: let's start at the top. stonematt, you just opened one

<burn> #164

stonematt: this is realted to a comment DavidC made in I think #135
... I think it's a ToU case, just needed to write it down
... how long something can live before being re-issued
... prospectus is covered by patty diver use case
... covers the bit about having to be online or not
... one of us should own this and take it home
... I think I can take it from a use case perspective but need help from a data model perspective

tzviya: not volunteering but had a conversation with benjamin about this, I think there's confusion between a terms of use use case and terms of service use case, we don't have a ToS use case

stonematt: can you define ToS?

tzviya: lots of websites have ToS for use of the website, etc
... eg "I use facebook and agree to facebook's use"

stonematt: almost like an EULA

tzviya: it is

burn: don't want to go too far down the issue
... we need to find out if we need to split off a separate issue
... could you put the comment in the issue to track?

tzviya: sure

burn: stonematt, can you assign yourself?

stonematt: sure

burn: #161 on vc test suite requirements, please review
... feels more like a call for help than an issue

<burn> cwebber: i have collected feedback already. I think we can close the issue here

stonematt: should we link to this in our README?

<burn> cwebber: Not sure it should go into the readme. Questions about 'how do we do this' are not good long term. Ideally we'll have test suite items or github issues

stonematt: should we capture the link to the VC test suite in the README

cwebber2: sure

https://github.com/w3c/vc-test-suite

<burn> ACTION: Matt will update readme with link to test cases

burn: ok, so I'm going to go ahead and close the.. I tell you what, in 161 put a link to that then close the issue

stonematt: ok I'll do it

burn: ok
... 158
... add critical property fields, opened by manu
... there's already a good bit of discussion on this one
... the idea is we may want to have a critical property part of the extension
... it must be understood and processed by the verifier
... David and Dave had comments here
... DavidC since you're here and manu and dlongley don't appear to be, are you willing to take on this?

DavidC: sure, but I'm having trouble finding about when we move forward, when we have consensus, when we make action? if manu makes an action and a PR before its resolved... who drives it?

burn: ideally the person who filed the issue took charge of driving the issue, so either we close the PR and the commenter is satisfied or we decide to close with inaction
... if you disagreed here, then we need to have more conversation

DavidC: but that just happened with the extensibility section

burn: I see that... that's a process question. each group does it a little bit differently. This is the first time this has happened in kind of a glaring way. Manu's been the primary active editor on the spec. He will tend to merge if he doesn't think there's a disagreement
... this is a bit surprising when I think there's a disagreement outstanding

DavidC: I was surprised

burn: this needs to stay open, I'll put a comment in there

DavidC: I think the same comment also applies to extensiblity and vulnerability

burn: part of the thing is we're tryingto move forward, and sometimes if someone responds and don't see a response from the other party, they're more likely to merge just to keep things moving. but that's not to mean that he gets to veto or override you, it's just to move forward

DavidC: and that's fine, if I'm technically incorrect then that's fine

bigbluehat: I stumbled across the same thing, but he did reference that there were two issues being discussed on that PR, which he references 158 as addressing David's remaining concerns
... trying to have less swords to juggle
... I know someone trying to test with the testing and implementation having so many PRs makes it hard to understand state of machine? and consensus
... I would expect some of this would go in before it's completely one, and more issues and PRs can and should be coming along, which I think is what manu was getting at with referencing the 158 issue
... DavidC, I don't think he was trying to override you or the process, just trying to do process

burn: some people say wait before merging, some people say merge and then fix

DavidC: that's what I wasn't sure, whether you had to patch it back, or remove a patch

bigbluehat: one of your comments you mentioned essentially a place wehre the language in the PR says "context will produce an error" and it must be a MUST
... so for those kinds of things maybe not worth filing a PR

DavidC: I agree

burn: i tend to lean on agreement before merging a PR, but let's just leave this one open. I left a note, you should both see it

DavidC: right

burn: just keep on top of it

DavidC: I just don't want to have people try to implement and find security holes

<stonematt> Probably should try to explicitly agree to the follow up tasks when there's a merge that needs continued work.

burn: fairly soon there should be a change where we're more restrictive as in terms of what changes to accept
... you are assigned on this one

#157

burn: does extensibility lead to vulnerability
... this is a question you had brought up, just wanted to make sure it was captured
... one more then we'll switch to the other toipc

burn: #149
... Need to restrict top level data types to those specified in the standard
... has this been done?

DavidC: it hasn't, but I think it can be done... if the text says type MUST be Credential or Profile, then I think that would handle it, but I don't think we have the text in there

burn: could you file the issue, and then we'll find what needs to happen
... in interest of time we need to move on

Focal Usecase (education w/ terms of use)

<burn> https://goo.gl/Vg7yMj

JoeAndrieu: so we have a draft of each of what we hope will be the three focal use cases we settle one

JoeAndrieu: the second one we focus on, the first one we want to talk about is the Patty Expert Instructor
... have a hook for ToU and ocap
... Each of these things are issued
... so you have a capability to update those credentials
... so they were hired after a date, then they reneweed some credentials, then FEMA needs to re-verify that the presentation is still valid
... this gives sort of an outline
... in terms of credentials we're just dealing with the certifications
... and the verifiable presentation is the one they submitted with their application
... and when they submitted that they were given some capability
... the trust heirarchy for this use case is that PADI is responsible for certifying diver schools, dive schools responsible for certifying pat's knowledge and skills, Pat is liable for representing facts in application and maintainng revocable capability, FEMA is liable for verifying credentials and Pat's assertions claming them

<burn> cwebber: you mentioned something I've been thinking about. a use case: a capability where someone gives permission to give a credential about themselves to some other entity

<burn> ... a VC may itself be an acceptable capability invocation

<burn> ... this is a mechanism to give permission to canonically extend someone's model

I need to type it up :)

stonematt: I think one of the parts of this application is that you're giving permission to continuously verify my status
... not just to verify the status, but to dial home and verify it's in good standing

<burn> cwebber: not the same as what I said. What I said is tangential. Your use case is valid.

cwebber2: I think that's not what I was talking about but it's a totally valid use case

DavidC: what I don't understand is the revokeable use case
... I don't understand why you would give someone who isn't the issuer permission to revoke

JoeAndrieu: the point is the ability for the employer to know my credential status, I may want to revoke that after I'm no longer their employee

stonematt: to be clear we're not revoking the credential but the permission to go check later

DavidC: ah I understand now

JoeAndrieu: it's essentially about ToU and privacy, and how can our hero Pat have some privacy around their credential status
... maybe capabilities could provide some privacy-enhancing mechanism
... let's highlight here's where you may use a capability

<JoeAndrieu> Dominode

<Identitwyoman> Dominode

Identitwyoman: the folks from Dominode have a use case similar to this

tzviya: I just wanted to.. when we were working on this use case, we were concerned that PADI would be viewed as recreational even though we brought in the FEMA use case. parallel use case to nursing use case

<Identitwyoman> dominode.com also Lily from Vouch ID - looking at Medical credentiallying

tzviya: should we switch this to a nursing use case?

<Identitwyoman> she would be the woman to talk about the nursing use case

stonematt: yes there are many employment scenarios where this occurs

agropper: I wanted to mention this in passing, this particular use case is getting very close to overlapping with the authorization server standards that I'm talking about in the agency self-soveriegn identity stack sense. I don't have a specific comment right now, but I will review the text as it's working up. Once we start to get into the negotiation of privacy and data minimization between requesting party (employer) and the subject of the claim in

which case is the diver/employee, that data minimization / authorization in the ocap sense is drifting into a domain that is subject to other standards that I'm very much trying to keep aligned

DavidC: it's an interesting use case, I don't think we should necessarily because there's a thing called capabilities that to say that there's a place to put them in, only if there's a use case... terms of use I see a need for, I don't think FEMA needs any permission to check if they check your permissions or not
... I don't think FEMA needs any permission to check if the applicant's VCs are valid or revoked. This is a given for using VCs
... there's an issue of when the credential is refreshed, how does the verifier see it
... is it the employee's responsibility to keep it up to date or not?
... I once had a passport when I was at ??, but since changing the employment I didn't have to bring it back to show them
... I think that has to be discussed with whether that makes sense or not
... I think it's perfectly reasonable in Terms of Use to put in the profile to say "you can only use these while you're employed, while you're not employed you can't keep checking on me any more". You don't need a capability for that. You may want to put it on as an authorizaiton system to use it or not

<stonematt> capability is an implementation of the concept "terms of use" there may be other technologies that solve this concept.

<burn> cwebber: this is a good use case for capabilities. this is a mechanism to check the status.

<burn> ... whether it should be cap or ToU is a longer discussion. Maybe not as much automatic machinery. If program evaluating, cap is better. If human, then ToU

stonematt: we have 5 minutes so let's move fast, so the point of this DavidC is that we have two competing concerns in terms of privacy, the diver should be able to take away the employer to keep trolling their status. It is the holder's responsibility to grant permission to monitor in this case. PADY is not necessarily subject to FOIA or etc, it's part of employment. when it ends, it should be turned off

<burn> I think 'it should be turned off' -> 'the employee should be able to turn it off'

<stonematt> FEMA only has that right as long as Pat is an employee.

JoeAndrieu: mostly want to echo that, I think DavidC you highlighted yourself that capabilities are one way to do terms of use... you can trust them to use ToU, or you can hand them a capability to do it. FEMA doesn't have permission to access my anything as a counterpoint, and the point of these use cases is to help identify sticky wickets / to identify ways to do things. hopefully that test of interestingness satisfies... that's all.
... so this is good feedback, I'm not sure we addressed all of DavidC's concerns but I was glad to get that input

stonematt: the museum repriprocity one was the 3rd?

JoeAndrieu: no, the parents traveling with child internationally

<DavidC> @cwebber2 Please correct this 'I don't think FEMA needs any permission to check if they check your permissions or not' to

JoeAndrieu: that's a real life use case tzviya has been working with

<DavidC> I don't think FEMA needs any permission to check if the applicant's VCs are valid or revoked. This is a given for using VCs

stonematt: should we get it into respec form etc?

JoeAndrieu: I'd like to keep it open for more convo and then will get it in respec

<stonematt> ACTION: joe to move doc to respec after we discuss the 3rd focal case

- DRAFT -

Verifiable Claims Working Group

24 Apr 2018

Attendees

Contents

Agenda review, Introductions, Re-introductions (5 min)

Action Item Review

Assign owners to unassigned issues

Focal Usecase (education w/ terms of use)

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output