- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 13 Sep 2018 03:26:24 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2018/09/11-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Benjamin!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
VCWG Telco
11 Sep 2018
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2018Sep/0001.html
Attendees
Present
Matt_Stone, Adrian_Gropper, Alex_Ortiz, Allen_Brown
Benjamin_Young, Brent_Zundel, Chris_Webber,
Clare_Nelson, Daniel_Hardman, David_Chadwick,
Gregory_Natran, Gregg_Kellogg, Kaliya_Young, Ken_Ebert,
Lovesh_Harchandani, Mike_Lodder, Ted_Thibodeau,
Tim_Tibbals, Yancy_Ribbens, Kaz_Ashimura
Regrets
Dan_Burnett
Chair
stonematt
Scribe
bigbluehat
Contents
* [3]Topics
1. [4]Unassigned issues
2. [5]Most Stagnant Issues
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<stonematt>
[8]https://docs.google.com/spreadsheets/d/1XIRn3VltrK_Dxqz0VyDx
Pi265sW47EMSKVKUXmMkI70/edit#gid=0
[8] https://docs.google.com/spreadsheets/d/1XIRn3VltrK_Dxqz0VyDxPi265sW47EMSKVKUXmMkI70/edit#gid=0
Unassigned issues
<stonematt>
[9]https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Ais
sue+is%3Aopen+no%3Aassignee
[9] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+no:assignee
<scribe> scribenick: bigbluehat
[10]https://github.com/w3c/vc-data-model/issues?utf8=%E2%9C%93&
q=is%3Aissue+is%3Aopen+no%3Aassignee
[10] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+no:assignee
stonematt: unless others have input on these from other groups,
I've not got more to add on this topic
Most Stagnant Issues
stonematt: reminder. TPAC is not far away. hopefully you've got
your travel plans booked!
... we'd like to get these issues lists ready for that
face-to-face
... hopefully anything not closed before then, can be closed
there
<stonematt>
[11]https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Ai
ssue+is%3Aopen+sort%3Aupdated-asc++-label%3Adefer+
[11] https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is:issue+is:open+sort:updated-asc++-label:defer+
stonematt: the one at the top of the list is
[12]https://github.com/w3c/vc-data-model/issues/72
[12] https://github.com/w3c/vc-data-model/issues/72
<stonematt> [13]https://github.com/w3c/vc-data-model/issues/72
[13] https://github.com/w3c/vc-data-model/issues/72
<cwebber2> [14]https://github.com/w3c/vc-data-model/pull/229
[14] https://github.com/w3c/vc-data-model/pull/229
<stonematt> [15]https://github.com/w3c/vc-data-model/pull/229
[15] https://github.com/w3c/vc-data-model/pull/229
stonematt: DavidC can you position this issue for us?
DavidC: there's been discussion that OCAP solves some of this,
but my review is that OCAP can be subsumed within the VC work
here.
... for instance the confused deputy problem was often cited
... but I think that's spurious
... we could equally provide similar things into the VC to
prevent those scenarios
... and now there seems to be an effort to downgrade what a VC
is to something less than a credential
... for instance, we have widely known authorization systems
that use subjects and attributes
... and it separates the problem of managing people with
managing credentials
<Identitywoman> That model is centered on the ENTERPRISE
identity and access managemnet
cwebber2: so why don't I get an overview of this PR and what it
says
... there is a section at the top that states that VC does not
itself provide an authorization mechanism
<Identitywoman> Verifiable Credentials is all about a whole
range of potential attributes/crentials/claims - including
"this student was in my yoga class yesterday"
cwebber2: later on there's a terms of use discussion
... it specifies how a VC document can be used or distributed
... it says that both credentials and profiles can be used
... it also says that profiles which wrap credentials must have
terms which match the credentials it wraps
... there some text here which might help clarify--which I'll
read briefly
... the text is here
[16]https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/
229.html#x6-2-terms-of-use
... with specific examples such as Alice enrolling with a new
primary care provider
... this does not get into the details of how this might be
protocol enforced
... the documents state how they should be followed, and Carol
could violate Alice's rights
... because enforcement happens out of bad from the credentials
themselves
... the purpose of this Terms of Use section is that Alice is
stating the terms, but that statement does not cause them to be
enforced
... perhaps we can talk about this section first, and then
after that discuss the authority section
[16] https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/229.html#x6-2-terms-of-use
<mike-lodder> I don't think it is
cwebber2: I'd like to get a sense from the room about the Terms
of Use section
daniel: I was working to change profile to presentation--is
that a problem?
cwebber2: sorry...I'd meant for the PR to use the term
presentation
<stonematt_> Presentation is preferred over Profile
daniel: yeah. there are a few places that needs fixing
... there's also a place where you say " A profile which wraps
credentials must be interpreted of having its terms of use
through aggregation of the respective credential plus the
wrapping profile. "
... there's an issue elsewhere that highlight that this
wrapping approach can't actually work
... in a zero knowledge proof world, you can't assume the terms
of use from the credential itself
... for instance, if I use a passport to determine your name,
then the terms of service of the passport itself cover the use
of the name within it
cwebber2: I'd be happy to discuss that more
... especially if there's some system for subsetting that I'm
not aware of.
daniel: how would we discuss this? on 224? or on your PR?
cwebber2: I'll join the conversation on 224, and we can go from
there
daniel: sounds good.
ClareNelson: howdy from texas! I have a comment from a high
level and a low level
... from a high level, if we're going to make this future
proof, then we should define things like ZKP, etc.
... many people do Zero Knowledge Proof approaches in different
ways
... so we may need to name this something else rather than
stretch ZKP's definition
<mike-lodder> ZKP's don't really work for terms of use because
verifiers have to read it
ClareNelson: and the other issue is in 224, legal topics
surfaced
... if legal issues need specific discussion, we should raise
that
DavidC: what we're working to define conformance, and the way
this PR removes some MUSTs form the Terms of Use we make it
harder to conform
... the proposed changes to the text is much more difficult to
actually use the Terms of Use
... in the previous text it was much more focused on making the
text usable by a verifier
cwebber2: so, the current text attempts to clarify that when
Alice is sharing the presentation to Carol
... what can Alice expect Carol to see and what she should not
expect
... it does currently use a SHOULD
... we could move that to a MUST
... but in a certain sense, this is very hard to test for a
MUST
... for instance, why is this policy vs. protocol level
enforcement
... if the terms were violated at the protocol level, it may
not be clear to Alice that it's been violated
... we have a need to have non-technical terms of use here
expressed in these credentials
... but the issuer can't then get a verifiable proof that those
terms have been operated on correctly from a technical
perspective
AlexOrtiz: if Carol passes Alice's presentation on to Dave
... do we write the spec such that we prevent that sharing
completely?
... because otherwise wouldn't Carol have to authenticate as
Alice?
stonematt_: I'm wanting to clarify some things generally
... one approach a VC may include a Terms of Use, but the
protocol won't know or care because it's not necessarily
enforceable
... but then we have the caveat of how does ZKP world present
that?
... and then we have a need for a use case and scenarios that
make this understandable
... so, we have a packaging question--how do we put ToU in a
VC, and then we have the distribution problem
DavidC_: following your train of thought...
... we have to say what it contains
... so the Verifier knows that it follows the data model
... I don't think we need the next bit about forwarding it you
have to include it
<cwebber2> yes I agree with that
DavidC_: it's signed already, so that's implied
<stonematt_> +1 to DavidC_
<ClareNelson> +1 to DavidC_
DavidC_: there was some text removed, which I think cwebber2 is
putting back
<TallTed> +1 data model vs protocol, again... does this matter
to the model? I'm hearing a lot about protocol again... "the
verifier must do..." is protocol, not model!
DavidC_: something about the holder adding additional terms
<stonematt_> +1 Data Model scope.
DavidC_: if your a non-conformant verifier, then you can do
whatever you want
... but if you are conformant, then you'd play by the rules
<ClareNelson> +1 Data Model scope.
stonematt_: just to be clear, everything about actual
verification is protocol level
... and we'll deal with that later/elsewhere
... so let's focus on data model concerns
cwebber2: there's not really a way to prove that someone hasn't
passed on information
... if I tell you privately that I'm a fan of red ties, and I
ask you not to tell anyone
... I can't prove whether or not you ever have told anyone
else, but I can certainly ask you not to
... so a conforming client would abide by that
... but it's not possible for us to enforce that a conformant
client would actually do that
... I had a point number 2, but I think I'll extract the
authorization stuff and move it to a separate PR
<stonematt_> +1 to simplify the PR to focus on Terms of Use
cwebber2: so DavidC_ are you OK with stating that these terms
of use things can be stated, but there's no guarantee that
those terms will be obeyed
DavidC_: we need to state that our trust model is that a
trustworthy verifier will obey the terms of use
cwebber2: but if I trust my doctor, I still have no guarantees
that I will always have that trust or that it's even correctly
placed in the first place
DavidC_: what we should say is, this is the circle, once you go
outside the trust model anything can happen
... as soon as you go outside the circle, you're outside the
circle and anything can happen
<Zakim> TallTed, you wanted to wonder whether it's time to
start considering a recharter to work on *basic* protocol that
informs the *basic* model, which is needed before the
*advanced*
TallTed: I'm concerned again, still, that we cannot seem to
stay focused on the shape of the data
... that's this groups charter, focus, everything
... the discussion now is about trust and enforcement
<cwebber2> +1 you can't guarantee trust
TallTed: and the only real way to do any of that is encryption
... and that's not what we're building here--as I was told when
I joined
<Identitywoman> it is about credentials.
<Identitywoman> not about opinions.
TallTed: this data model is about "did joe say I'm a bad
person" and maybe some metadata about then he said it
... this cannot then be about the content of what was said
... it's about did this content come from that emitter
... there's a bit about protocol, but we're far away from that
basic stuff
cwebber2: I agree with TallTed. there's no guaranteed trust
model outside of cryptographic trust
... but we did add this terms of use section
... if we're adding that, then we are already stating that will
be some expections
... however, no matter what protocol is used, you cannot
guarantee that someone will store a credential in their
database
<TallTed> "Terms of Use" is a guidance. That's all it can ever
be.
cwebber2: but if we leave terms of use there, then we're giving
them the impression that they can actually put limits on its
use
... even though that's clearly not technically possible
... the purpose of this whole section is to state that it might
be ignored
TallTed: it's wishes in the side
... if I give stuff to my doctor, there are laws, etc, that
attempt to enforce our contractual violation
... but they still might put it on billboards or whatever
... the enforcement of that contractual violation is way beyond
scope for this group
... we can't hope to list or prevent every possible problem
that might come up
DavidC_: the point for having the terms of use in the data
model is to say, these are the semantics of this field
TallTed: perhaps we might reword it to intended audience, etc,
which might be clearer
<cwebber2> I agree that's a subset
DavidC_: that's a subset of it...that part of terms of use
... but there's more beyond that
... by calling it terms of use we're a level higher
<stonematt_> we shouldn't care what's in the ToU
DavidC_: we're trying to provide the semantics for providing
that content
... and what it's purpose is
... the model says, this what it is and this is how it's used
... we shouldn't go beyond that into the area of bad protocol
usage, etc.
TallTed: those sorts of things continue to come up in previous
calls, though, which is why I've again raised this concern
<TallTed> "Terms of Use" *can* be read to communicate some
feeling of restriction/enforcement, but doesn't really govern
anything ... so perhaps it should have a different label
DavidC_: all of those bad scenarios exist, but I don't think we
should attempt to state them all--as the possible error
scenarios are infinite
stonematt_: given that this is not strictly about the data
model and mostly about protocol and usage
<mike-lodder> +1 to remove
<cwebber2> I object
stonematt_: I'd like to propose we remove it
<DavidC_> +1 to remove
cwebber2: there are 2 parts of this PR
... one is terms of use--which is where all our time went today
... the other is authorization
... the reason those are related, is that having this data here
introduces the possibility of using this at a protocol level
... and thereby providing a foundation for protocols to use
these things within a protocol
... I agree there is the potential for readers of the spec to
confuse the inforceability of this section
... and we should make it very clear what our intentions are
here
stonematt_: we've got 2 minutes left
... cwebber2 I'd like to suggest we break this PR into two
pieces
cwebber2: happy to do it
stonematt_: maybe today was helpful for at least tweaking this
and the other PR
cwebber2: ok. great.
stonematt_: thx
... any closing remarks?
DavidC_: just a closing remark. I think this is fundamental to
our work
stonematt_: we're certainly spending a lot of time here, so it
probably does show that it's important
<TallTed> no argument about importance overall -- just *where*
this belongs
Tim_Tibbals: I'd like to say that for scenarios like this,
other groups have simply pointed to other peoples definitions
of things like "terms of use"
... perhaps we can do that and avoid the problem that way
<cwebber2> ok
stonematt_: thx for the advice.
... it's top of the hour, and we'll see you at the next thing
<kaz> [adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [17]scribe.perl version
1.152 ([18]CVS log)
$Date: 2018/09/12 18:22:45 $
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 12 September 2018 18:27:35 UTC