Minutes for VCWG telecon 11 September 2018

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