<scribe> scribenick: bigbluehat
<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.
<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.
<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
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
burn: any more thoughts before we move on?
stonematt: to help us get our discussion going toward this terms of use
<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?
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/Regrets: Tzviya_Siegman// Succeeded: s/thanks Manu// Succeeded: s/Topic: PR review != PR169// Succeeded: s/solving/signing/ Succeeded: s/unnecessariy/unnecessarily/ Succeeded: s/Sovern/Sovrin/ Succeeded: s/I can see the submitter action/I have cancelled the submitter action/ Succeeded: s/______/a licensed professional granting permission\/capability to employer/ Succeeded: s/includ/include/ Present: Allen_Brown Benjamin_Young Chris_Webber Dan_Burnett Dave_Longley David_Chadwick Liam_Quin Manu_Sporny Matt_Stone Ted_Thibodeau kim_hamilton_duffy Regrets: Tzviya_Siegman Joe_Andrieu Found ScribeNick: bigbluehat Inferring Scribes: bigbluehat Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018May/0008.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: manu WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]