Verifiable Claims Working Group -- 15 May 2018

<scribe> scribenick: bigbluehat

Agenda review, Introductions, Re-introductions

<burn> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018May/0008.html

burn: assign issues which are unassigned and review pull requests
... there's plenty of discussion happening on some of these PRs and it'd be great to get these merged in
... another topic is machine readable terms--which would be great to discuss today
... the other if time permits is threat model updates
... any other topics?
... so, let's go ahead and move on to action items.

Action Item Review

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

burn: the action items are things that have come up in calls, but have not yet made it to GitHub in one form or another
... if we look at line 30 in the above spreedsheet
... Chris, could you give us an update on this one?

cwebber2: yes. Nathan and I had an offline conversation about this
... and I was asking for examples that we could analyze for testing needs
... but maybe I should reping him as I don't yet have the examples needed

burn: so, line 32 is next
... I believe we're still needing the 3rd focal use case

stonematt: I think we're on our way to having this ready and can remove it from this list

burn: do you mean there's a draft available?

stonematt: there is a respec draft of use cases available

burn: ok. then this is removable
... next is line 33. This one's pending some activity from Richard.
... the chairs will make a call on iceboxing that one, though, if we don't hear back soon.
... next is line 36

DavidC: I was away on holiday, and spent the weekend with a cold, so I'm behind on this one
... I'd like this one to stay on the list so that I can address them soon

burn: next is line 37 about SVG rendering; I believe that's in the same category?

DavidC: yes. same category.

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: oh. manu took one of these already, and the other two issues are deferred. Great! Thanks, Manu.
... great. so we can move on

<burn> https://github.com/w3c/vc-data-model/pulls

burn: we don't really want to discuss #169

manu: so. I'm running out of issues--which is nice.
... but that means I need to pick up a few that have other assignments
... do we want to reassign things?
... there are a ton of great comments that I'd like to address
... but is there a preference for reassigning issues from the chairs?

burn: this is my personal preference.
... there are a lot assigned to DavidC
... manu if you're available to look through those, and if you want to offer to take some that DavidC's not got time for, that'd be helpful

<manu> ACTION: Manu to look at open issues, pick any that need PRs and do them, discuss with DavidC on other issues.

stonematt: I think that's a good strategy. I wanted to make sure we spent at least a few minutes on the can of worms
... the one that Allen Brown that's embedded in that issue.
... there's really a lot in this issue
... and stuff needs to get teased out of it
... so I'm glad you picked that up, manu
... but let's try and make sure there's focused discussion with each of these

burn: there are indeed a large number of issues tangled into other issues as stonematt said

<manu> I can split the issue out into separate issues if necessary.

<manu> We'll start with a conversation.

burn: so manu feel free to extract the into separate ones to iterate independently
... anything else on this or other unassigned issues?

stonematt: one last thing before we move on
... manu, as you're tearing through that with Allen, if you want to put time on our agenda, please let us know

manu: will do

PR review != PR169

burn: so, let's start at the top
... 173...add security section on token binding

stonematt: manu, this might technically be above my head, but I fear I won't have much feedback on this one

manu: ok.

burn: let's leave https://github.com/w3c/vc-data-model/pull/173 open for now

manu: just to be clear issue #??? is waiting on DavidC to pull examples from it and resubmit

DavidC: oh. I'd misunderstood. I didn't understand those needed extraction

manu: my concern is that if the rest of those examples stay there, then they will receive comments
... so we shouldn't include examples that don't have concensus

burn: the reason I didn't bring that one up, there's conversation still happening on it
... so I wanted to avoid the conversations to day being just about this
... is there anything that you can do manu?

manu: no.

DavidC: I am going to progress it
... I'll consider removing them
... but there are several issues that are not resolved
... one example is signing
... I said they always need to be signed, and manu said, no they don't
... but we just left it in that disagreement
... because someone from Dutch Telecom or somewhere said they didn't need them
... but we've left that unaddressed

burn: as I've said, I don't really want to discuss this
... however, DavidC you do have some clear issues here
... so they should be filed as actual issues
... on GitHub, so they can be tracked explicitly
... that means those issues can be tracked specifically

DavidC: ok, then I will work to pinpoint issues from the longer rambling conversation issues

burn: I'll make one ore comment here
... if you're uncomfortable removing those, saying that they're non-normative does not tell people that there is lack of consensus
... I have seen groups put things in, but with an editorial note that states there's lack of consensus

cwebber2: some of the conversation that's happening on there is not a blocker to resolving the issue
... one such issue is are VC's already object capabilities in a more minimal way to OCAP-LD
... but resolving that doesn't need to block the specific issue where that discussion is happening

burn: it would be helpful, then, cwebber2 if you could move the conversation by making a new issue and referencing it from the existing one

stonematt: cwebber2 we might get a chance to come back to that topic when we get to machine readable terms of use later today
... but to keep us on topic here, we're looking for quick actions for PRs.
... and not necessarily trying to get into the debate individually
... which PR are we on?

burn: we're on https://github.com/w3c/vc-data-model/pull/172
... remove musts and shoulds from requirements
... that's exactly what manu did in this one
... I believe there are approvals
... dlongley and DavidC both say it's fine
... cwebber2 you're marked as a reviewer. Have you had a chance to?

<Zakim> manu, you wanted to ask burnburn to clarify what he mentioned in the PR comments?

<cwebber2> I haven't looke yet

<cwebber2> I will look right now

manu: you had a comment, burn, that was intriguing.
... the reason we made the changes was to avoid tests on them

<cwebber2> oh right, okay I think I did review this and it looks good to me

manu: and we have a section here to avoid other folks trying to change the spec unnecessarily

<stonematt> characteristics?

burn: it might just be the first sentence about "requirements" and then there are statements that are not requirements but explanatory or defining

<cwebber2> needs? :)

<dlongley> "goals"?

<dlongley> "requirements" => "goals"?

manu: if we remove them and describe them as "desirable characteristics" that would do the trick?

burn: yes. that'd be fine
... k. and cwebber2 says it looks good, so as soon as manu makes that change, he's free to merge that one

https://github.com/w3c/vc-data-model/pull/171

Revise "Profile" concept to "Presentation", per F2F consensus

burn: folks seem to be happy, but we don't have a review from Nathan yet--per the request
... these all seem editorial

manu: not sure I'd completely agree with that
... this change is required if we're going to get things like Sovern and Evernym using zero-knowledge proofs
... once we have more information about their use of "presentations"
... then we can address some of the difference between what they're doing vs. what we have expressed currently

burn: k. it looked to me only like a wording change
... I realize it that may have important consequences
... but not any core content changes

manu: at this moment, yes...but I think we have to wait on the rest of the changes until we hear back from Sovrin and Evernym

burn: gotcha. so these changes first, then larger ones.

DavidC: it looks good to me because it was an editorial only change
... but if there are changed meanings coming down the line, then that's a completely separate issue

burn: so we can merge it then?

DavidC: exactly.

https://github.com/w3c/vc-data-model/pull/170

burn: the whole ID thing is tangled up in that one...so let's skip it

https://github.com/w3c/vc-data-model/pull/169

burn: I think this one is blocked by #170

https://github.com/w3c/vc-data-model/pull/146

burn: I have cancelled the submitter action expressed in #146

https://github.com/w3c/vc-data-model/pull/145

Fixed Credential Status Scheme

burn: this one kinda didn't go anywhere
... opinions?

DavidC: basically, it's confusion between the tension and the example
... I added a "scheme id" to the example
... essentially, I want exact matching between text and examples

<Zakim> manu, you wanted to note that it breaks from JSON-LD data model.

manu: I don't know that is the "ID topic" because I'm not sure what that means, exactly
... there are two potential "ID topics" we need to discuss
... in JSON-LD when you state an ID, you do it in a consistent way
... in some cases, ID is already that thing
... and it has ramifications to the Data Model if we start renaming those

<dlongley> "id" is always the ID, that's a general rule... that needs to be understood and if we need to say that somewhere we could do that

manu: so if the desire is to align the text in the spec with what's in the example
... then we can do some styling things to highlight which id in the example is the scheme id
... the way that you do that identification in JSON-LD is you use `@id`
... what's being suggested in the PR breaks the data model
... by creating a currently ignored "scheme id"

<dlongley> i.e. let's address the issue not by using "schemeID" but with some other language

DavidC: if we look at this example we've got, credential status
... then the id is the id of the credential status
... but it's not the id of the scheme
... so the credential status can have multiple scheme
... I'm not an expert on JSON-LD, but I thought everthing had to have an id
... but if a credential status has multiple schemes?
... we need to be very precise in telling people what's what

dlongley: maybe what DavidC is saying is that we're making a distinction between an instance of the thing vs. the thing
... is that the distinction, DavidC?

DavidC: that is exactly it
... so we need to change something to make that more clear

dlongley: so we should change the text, but not the example

DavidC: yes. explaining things more clearly is what's needed

manu: would you want to edit yours?

DavidC: I don't know how to update PRs

manu: you jut add changes and repush to that branch

DavidC: what happens if the master document changes?

manu: in this case, it won't matter (though in other situations it might matter)

DavidC: k. I'll try that later today and get back with you if I have problems

burn: or, someone can make a PR based on his PR and we can then review that

manu: this time, let's have DavidC update his PR

burn: I think you'll be pleasantly surprised how easy it is DavidC

Getting to a PR for machine-readable ToU

burn: any more thoughts before we move on?

stonematt: to help us get our discussion going toward this terms of use

<burn> https://docs.google.com/document/d/1O-PYcHZYvbjbhONRSdSwdCP2cwg77bxadAJQdHdI66A/edit#heading=h.3xg6fhe9o2ua

<burn> ^ ToU topic

stonematt: we have an ongoing debate around things...still in flight
... but one thing we've narrowed in on in the use case document
... is around a licensed professional granting permission\/capability to employer
... that use case document's section 3.2.3 expresses that idea
... the idea here is that we have a verifier and a holder
... there's an idea of credentials that can be more dynamically updated
... there's an idea around permission to verify in the future which the holder can turn off
... my hope is that folks here could help discuss how this would be possibly solved by our current data model

cwebber2: I think there are two conversations here
... it's about enforcability around inbound vs. outbound
... the other is about ACL type things
... those are two different things, but I'll try to focus on the Terms of Use
... I did not mean to claim earlier that ToU's are not machine readable
... if you imagine the machinery that's checking it in one scenario might be reduceable to a "pass"/"fail"
... but then there are some other scenarios, such as third-party correlation
... there's no way to check that inbound, but it's still valuable to express
... it's just well beyond a Boolean pass/fail scenario

<Zakim> manu, you wanted to mention we may have two types of terms of use -- legal vs. operational.

cwebber2: so, they may be machine expressible, but not machine enforceable in the same way

manu: to build on what cwebber2 is saying
... I think what we're after is a framework for discussing this
... I don't think we have things clearly delineated in the specification
... fundamentally, there are things that we are never going to be able to enforce from a machine perspective
... maybe in 100 years we can express everything and verify it all with machines
... but in the next 10 years, we can't do things like verify that "don't track me" (for instance) is being enforced
... so "don't track me" is a verifiable credential use case, not an OCAP use case
... whereas permission to use someone's digital wallet is a Object Capability use case
... if this is an Object Capability use case, then we should remove it

<Zakim> cwebber, you wanted to talk about VCs and "ACLs vs ocaps" convo

<cwebber2> https://github.com/w3c/vc-data-model/pull/169#discussion_r186262983

manu: but if it is a non-OCAP-based use case, then we should include it--and work to focus on those.

cwebber2: some clarity happened on the link above

<stonematt> that's a huge assertion about use cases that I don't agree with (yet)

cwebber2: around some of this confusion
... some of this is an identity and authority use case
... and the other is authority by posession
... you combine identity and authority, you get to ACL
... but when you have authority by possession, then you get to OCAP
... the OCAP-LD spec is not a bearer capability system
... it does have a field where you grant some capability, but it's more of a toggle to "turn on" that capability
... I don't disagree that you can do bearer capabilities with VCs
... but the risk if when it gets conflated with verfiability around a subject

stonematt: I wanted to key off something manu said
... it might help us next time we discuss this
... if we need to rethink the use cases we want to express
... to more fundamentally these use cases in light of what people will expect to find here
... I feel this discussion is currently way to abstract and not actionable
... so that's the topic, how do we write a use case that's bounded by the boundaries we're not living within

<dlongley> VCs are about identity -- saying what attributes people have, making statements about the characteristics of things ... you could decide to let someone DO something (authorize them) based on their characteristics, but the way you should do that is to give them a KEY to thing they are allowed to do ... that "KEY" is an OCAP... OCAPs make authorization *explicit* through keys.

<Zakim> manu, you wanted to say he has some thoughts on how to do that.

DavidC: we've got two different formats, and it's not clear how do you stop one of the concepts in format 1 from being encoded in format 2

manu: I have some thoughts, that could help stonematt but we'll take it offline

burn: tnx all! see you on the CCG call

<stonematt> by all!

<DavidC> @bigbluehat What I said was, if I make the subject ID in a VC a key, then is that an OCAP or not?

- DRAFT -

Verifiable Claims Working Group

15 May 2018

Attendees

Contents

Agenda review, Introductions, Re-introductions

Action Item Review

Assign owners to unassigned issues

PR review != PR169

Getting to a PR for machine-readable ToU

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output