<stonematt> https://docs.google.com/spreadsheets/d/1XIRn3VltrK_Dxqz0VyDxPi265sW47EMSKVKUXmMkI70/edit#gid=0

Unassigned issues

<stonematt> https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Aissue+is%3Aopen+no%3Aassignee

<scribe> scribenick: bigbluehat

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

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> https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc++-label%3Adefer+

stonematt: the one at the top of the list is https://github.com/w3c/vc-data-model/issues/72

<stonematt> https://github.com/w3c/vc-data-model/issues/72

<cwebber2> https://github.com/w3c/vc-data-model/pull/229

<stonematt> 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 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

<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]