<scribe> scribenick: dlongley

stonematt: Apologies for no agenda today. As we roll into getting these big tasks done, I'd like to spend most of the call today on the discussion on Terms Of Use.
... We had a JWT call yesterday and we have a similar one for ZKP next week.
... We haven't done the same thing for Terms Of Use so I think it would be worthwhile to use this time for that topic. We use most of the hour for status and approach and hopefully some actions on Terms Of Use and how to address that. That ok, any objections?

<DavidC> +1 to ToU

manu: No objections to that, that's a good use of time. I did want to mention that we have 15 open PRs and we have some feedback but would prefer feedback on the ones we don't have any responses to. I really would like to start merging those as quickly as possible.
... I think we have a seven day window where we'd like comments on PRs and that window has all but closed on many of them. Please look at them, reminder to the group. I will merge if no suggestions/non-controversy.
... Particularly the CR blocker ones.
... I will probably start merging on Saturday.

stonematt: Duly noted, thank you.
... Any newcomers to the call?

none

Terms of Use

stonematt: Terms of Use has been a topic where it seems like the boundaries of scope; the recognition of Terms Of Use is a protocol problem but expression a data model problem.
... We often get stuck talking about the recognition instead of staying focused on the expression which is our domain and scope per the charter.
... So, just a reminder for the discussion today -- obviously the way we express it may affect how we recognize it but let's keep it in bounds.
... David Chadwick -- you've been a strong proponent of this idea over the last few minutes, can you say where are we and what needs to be decided with the discussion right now?

<Zakim> manu, you wanted to note PRs pending...

DavidC: The interesting discussion I had with Manu -- a slight digression but it's important. Issue #252 ... towards the end we looked at what a VC is about and what do they control. Manu proposed 4 steps and I expanded that into 8 steps. I haven't had any comments on the 8 steps yet.

<manu> https://github.com/w3c/vc-data-model/issues/252

DavidC: But it's relevant, given our model of Issuer/Holder/Verifier, what do we envisage is the usage of VC and this says what the 8 steps are -- and what steps do we cover in our document? I think we have clarity on issuance of VCs and verification of VCs, all within scope. Clearly we have nothing to do with the verifier defining access control, not in scope. But listing these steps and saying what we should be covering is important.
... And Terms Of Use -- do they cover any of these steps? I pointed out one contentious step which is step 6 -- and I think it should be covered in our doc. We have a model about how VCs flow and how they are dealt with and we should be clear about the steps. If we can resolve that and we can agree on that it might help the rest of the discussions.

Dmitri: Can you state the steps for those that don't have them in front of us?

<stonematt> The verifier defines its access control policy

<stonematt> The issuer(s) issue(s) VCs to the holder

<stonematt> The holder may pass on the VCs to another holder

<stonematt> The final holder presents the VCs to the verifier

<stonematt> The verifier verifies the authenticity of the VCs

<stonematt> The verifier verifies the right of the holder to posses the VCs

<stonematt> The verifier's policy decision point evaluates the credentials against the access control policy and returns an access control decision

<stonematt> The verifier grants or denies access based on the access control decision.

https://github.com/w3c/vc-data-model/issues/252#issuecomment-439008441

DavidC: I think step 6 should be in the scope of our document ("6. The verifier verifies the right of the holder to posses the VCs") because step 3 is ("3. The holder may pass on the VCs to another holder").
... Because our model has in it that VCs are passed on, that our model should also have in it that the control of that and to notify the verifier that it has happened.

TallTed: Very much of this reads to me as protocol level stuff. If we're actually really truly doing what we've said we're doing, which is building a data model. It's a structure. It has zero to do with verifying the right of anybody to do anything. That's part of whether or not the access control decision happens and even what happens with the crypto.
... I'm seeing lots of feature creep.

dmitri: I have a slightly more fundamental question -- I agree that this is worth discussing whether this is in scope -- my question is ... it's my understanding that our threat model is that possession equals authority. If you manage to get your hands on them and on the keys, you're authorized.
... If you have the keys you can prove possession of the credential.

DavidC: That would only be the subject right?

<Zakim> manu, you wanted to note that this is protocol layer stuff... the data model enables this particular flow, but it is *a* flow.

manu: I think understand what you're saying Dmitri -- but it makes it sound... it may have confused people. Technically if you have the credential AND the keys, i.e. you have the whole wallet, then you can assert you are the subject then maybe you can authorize.
... I want to go back to what Ted was saying and I think we're into protocol and this is feature creep, I agree. But I do understand that David wants to say something about this in the spec -- and sometimes it's useful to say something even in non-normative ways. I think what he's saying is that the spec doesn't talk about, for example, handing off a prescription to a care giver who picks it up on your behalf.
... It may help to give some elaboration on such a use case in the privacy consideration section -- I would be ok with doing that. I would personally draw the line about making normative statements about how you do this and that's protocol as Ted said and it gets complicated quickly.

<brentz> +1 to not making these 8 steps normative

DavidC: Couple of things. We have the data model and we do indicate these flows. I think we need to have more details like the 8 steps I have listed. All the use cases are using these 8 steps and about passing VCs around and giving them to verifiers and it's only elaborating on what our model is. We aren't saying How they are passed around, so it's not protocol. We're saying this is our data model and architecture.
... We all agree on not defining protocol and it's all independent of that. Our data model should be able to control architecture and flow independent of the protocol.

<stonematt> reminder that we're speaking about https://github.com/w3c/vc-data-model/issues/252#issuecomment-439008441

JoeAndrieu: I apologize for missing the opening because this is awesome. I wanted to respond to Dmitri's suggestion that if you have the credentials and the keys then you are authorized. I think that aligns with this notion that VCs can be authorization and I think that's a huge, huge problem.
... Treating VCs as authorization brings up a whole bucket of problems. A statement that my hair is brown does not authorize me to do anything. I don't know how to avoid that conversation. One of our problems here is that we fetishize the control of the keys like that's a resolution ... and identity assurance and what truth is depends on more than just one VC and more than just one key.

<Zakim> TallTed, you wanted to talk about using more real-world examples -- passport, driver's license, credit card

TallTed: I think a lot of where this wheel spinning is coming from is a great deal of hypothetical situation. Not just the hypothetical of "I have a passport that says I'm a citizen of the US" but "I have a credential and it says something." The vaguer the stuff we are talking about the less coherent any of our consideration can be.

<JoeAndrieu> +1 for specifics

TallTed: If you talk about a passport we can all understand that physical document and I think what we're trying to do is bring some of that physical document into electronic space. Just because I have Joe's passport does not give me anything as far as authorization and doesn't say anything about me as the holder of that credential. The credential is verifiable and it is a valid document. But they are not about me -- I think we can all agree. You can tell

that when you compare the attributes of me as the holder with the attributes described in the document.

TallTed: These are the sorts of things that will be done and the model built here has to allow for those things to be done. But it cannot get into the weeds for this is how you decrypt or encrypt or confirm that I'm the holder of the thing -- there have to be hooks about the thing.
... There has to be some way of carrying the attributes of the authorized holder within this thing if we're going there but I don't think we actually want to honestly. We have three detailed pictures that start this document draft and they are extremely generic because they are not about VCs or claims or assertions or anything else, they are about RDF and the general structure thereof.
... Then we go into extremely broadbrush handwavy pictures and extremely details JSON examples which are not readable by most humans. I submit if JSON is the way to handle this ... turtle is the better way to express what we're talking about in the actual talking about it because it's more human readable. That gives us a very easy way to give us a picture. There are automated tools. If we don't produce that picture then we don't know what we're

talking about.

TallTed: We can't keep hammering about pushing PRs in and just going through -- we're not doing the job. We may produce a document that gets full approval but does nothing. End of rant.

<dmitriz> Turtle being more human-readable over JSON — that's definitely personal opinion :)

<manu> yeah, I don't buy that.

<Zakim> stonematt, you wanted to say verify difference between issue and present

<manu> but I think TallTed makes excellent other points :)

stonematt: Going to let that process for a bit. I'm going to get back to this idea ... and refine our use of vocabulary in this space. The issuer issues a credential to a holder and later they present it as a verifiable presentation to a verifier. So, two simple steps. Now we're introducing this idea of ... once it's given to me as the holder I want to give it to, say, Joe to present on my behalf. What do I do?
... Do I issue the credential to Joe or do I present the credential to Joe? I think I issue it, which gives a chain of custody but Joe is taking control of it ... and maybe there are some Terms Of Use that I can put on it as an issue in that transaction and that's later verified. And the thing that's verified is the one assigned to me. Am I thinking about this the right way?
... Do we already do it and just need non-normative text to describe it?

<Zakim> brentz, you wanted to say authorization is the realm of the verifier

brentz: In my understanding, the whole thing a VC ... does not indicate authorization of any kind, a verifier decides authorization. Possession of a VC doesn't indicate authorization at all.

<manu> +1 to brentz!

tzviya: To propose something to make everyone happen ... the section is non-normative. Perhaps we can craft some language around this around DavidC's suggestions and say how something might be implemented in the real world as an example. It's a little bit more robust than a use case and that's why it's in the spec but we're talking about what happens when this is used in the real world.
... We'd have to adjust the language to make it clear that not all of this is in the data model and Manu may be better at crafting this language than I am -- but incorporate more of the steps that David has proposed and make it clear they aren't part of the data model.

<Zakim> manu, you wanted to propose that a non-normative section is added to Privacy/Security section that covers what DavidC wants to cover... see if that would resolve the ToU #252

manu: So +1 to what Tzviya just said. So a direction question about resolving this...
... I believe that David wants to see text around this meta/pseudo use case. Previously when we've done this, we have for example, ... let's say David you want to put this in the Security Model section, what we can do is put a note in there, there's this alternative flow for passing VCs off to other people, and if you'd like to learn more about this go to the Security/Privacy section.
... In that section, in non-normative language, very clear we're talking about the larger ecosystem and this is a use case pattern we've seen, with someone else giving someone a VC and perhaps the prescription use case is one to talk about. And we elaborate there with what DavidC wants to talk about. It's clear to readers we want to talk about but draw some lines.
... It's not data model but there are some interesting use cases we've thought about and wanted to elaborate on. David, would that address your concerns and we could put this Terms Of Use thing to rest?

DavidC: I'd like to address all the speakers in order. First, Ted. Ted, I'd like you to turn to figure one of the data model document. You were talking about the later figures which were the RDF. The RDF is less important than figure one which is setting the scene.

<stonematt> https://w3c.github.io/vc-data-model/diagrams/ecosystem.svg

<DavidC> https://w3c.github.io/vc-data-model/#subject-holder-relationships

<manu> https://w3c.github.io/vc-data-model/#ecosystem-overview

DavidC: So you have a passport and an issuer and a verifier. All I'm saying is elaborating on this -- because this is our model. I want to say to Matt, in most cases the holder will be the subject and they will pass off to another holder. It isn't that the issuer gives off to any older holder, mostly they are given to the subject.
... In most cases, passports are sent directly to the subject and they have to sign for them. So you're addressing, the issuer gives it to the subject ... and in some cases the holder!=subject.
... I think we need to set that scene and this is the ecosystem we envisage. And say this is the limit of our ecosystem. We are dealing with the passing of the VCs regardless of protocol -- but it has to be passed in some way. To Brent, I totally agree with you that the passing of a VC does not authorize.
... You could get hold of a VC easily but that doesn't give you authority. Possession does not equal authorization.
... Manu to answer your question, yes I would be happy to put some text in. I've got a PR with non-normative text. I've got those eight steps that I'd like to put in and say this is how, in general, we expect to pass VCs around between entities.

<DavidC> Happy to write the text

manu: Great. David, I think because we have that PR in there you already have a pattern and I'd prefer that you write the text because I'm not super clear on what would be adequate on your point of view. The only disagreement at this point, I think, are the 8 steps. I agree that some use cases have those 8 steps but not all of them.
... For example, handing a VC off to someone else is a use case but not a central one. I am fine with elaborating those sets of steps in those non-normative sections but I don't want to assert that those steps are the most basic form of the ecosystem.

DavidC: If you read my wording carefully it says MAY. Step 3 is a MAY, step 4 is a MUST.

<Zakim> manu, you wanted to agrree with almost all if it, except for the 8 steps

<dmitriz> where are the 8 steps, in the spec? what section?

manu: That's better but I'm still a bit weary about overcomplicating the description of the ecosystem right out of the gate. That diagram we have is a gross oversimplification of the ecosystem. There are digital wallets in there, a VC could be passed off to do the actual verification, so on and so forth. We've simplified at the beginning of the document and I'd like to keep it that way.
... It's fine to elaborate on your steps in the non-normative section but I'm hesitant to add detail at the beginning of the document like that.
... The 8 steps don't exist in the spec.

<tzviya> https://github.com/w3c/vc-data-model/issues/252#issuecomment-439008441

DavidC: The 8 steps are in an issue.

<dmitriz> thanks!

DavidC: So what I'll do -- I agree Manu. Keep it simple in the beginning but later on when we get to holder!=subject it can go there as non-normative for example.

<brentz> +1 to concern with #3

manu: And rereading it's really only step 3 that I'm concerned about, but let's put it further down in the document.

DavidC: Certainly, I'll work on that and have it ready in the next day or two.

manu: Wonderful, thank you.

<dmitriz> whereas I'm definitely concerned about step #6, "The verifier verifies the right of the holder to posses the VCs". <- I think that's very application-specific.

<brentz> +1 to putting this in the subject != holder, if anywhere

<stonematt> +1 to putting this in line w/ the subject != holder discussion

DavidC: Step 6 is contentious -- if step 3 happens then our data model should have hooks to control step 3/6. If we say step 3 can exist then we ought to have some hooks in the data model something about step 3.

stonematt: It seems we might have some level of agreement. David Chadwick has an action item to modify PR text to reflect this agreement. Is it worthwhile trying to restate what we agree on?

dmitriz: Yes.

DavidC: We agreed that we will keep the data model simple at the beginning. At a later point in the document, when we talk about subject!=holder we introduce these 8 steps and say which are mandatory or not and then say why subject!=holder is there because it's actually talking about when the issuer gives it to the subject or to !subject or something else, etc. It will give people an idea as to why that section is there -- it's because of these 8 steps.

stonematt: Ok, any objections?

none

stonematt: Ok, let's move forward with that PR.
... Manu, since we have extra time do you want to run through PRs? Drive feedback on any close to close?

manu: Sure.
... Here are the open PRs:
... One thing I want to point out ... I'm going to talk a bit about ZKP and JWT stuff because we have Brent and Ken on the call today. We had a discussion around JWT.
... Topic: Open Pull Requests

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

Discussion around JWT -- https://www.w3.org/2018/11/19-vcwg-minutes.html

manu: There are now two potential approaches for transforming ZKP approaches -- to transform it into a VC. It would help if you guys read the minutes from the JWT thing and the PR so you understand the general approach we took there -- prior to the ZKP call.
... We failed to close the verifiable data registry bikeshed ... only resolution is to bikeshed the options and do an instant runoff vote. We've heard enough from people and we just need to vote and move on at this point.

<stonematt> +1 to instant runoff

<manu> https://github.com/w3c/vc-data-model/pull/263

<brentz> +1 to putting it up for a vote

<manu> https://github.com/w3c/vc-data-model/pull/277

manu: We are renaming "claim" to "credentialSubject" and there's a PR in there with two comments. If you have a strong suggestion there please make a note. I think Daniel Hardman from Evernym was concerned, Brent could you follow up?
... I think some of the Evernym/Sovrin folks were concerned about that, please give feedback if so.

<brentz> I'll ask Daniel

<manu> Use Cases need feedback on threat model -- https://github.com/w3c/vc-data-model/pull/278

manu: I haven't heard from the use cases team on the threat model.
... We point to a threat model in the use cases there -- I just need to know from Joe or anyone else on the use cases team if that's adequate. If it is we can resolve that issue.

<manu> Transitive Trust PR: https://github.com/w3c/vc-data-model/pull/279

manu: There's a PR in for the "no transitive" trust stuff -- if anybody else wants to think about that we'd like feedback on that.

<manu> Data Schemas PR: https://github.com/w3c/vc-data-model/pull/280

manu: There is a new proposal for a data schema language, this affects ZKPs and some of the stuff Bohdan wanted and some of the stuff David Chadwick wanted.
... We'd like to hear back from people on those.
... These PRs will all be merged this weekend if you don't object.
... We have two new ones from David Chadwick on deontic terms of use.

<manu> Deontic ToU: https://github.com/w3c/vc-data-model/pull/282

<manu> Moving delegation to non-normative spec text and to the bottom: https://github.com/w3c/vc-data-model/pull/283

manu: ...and on moving delegation to non-normative spec text and to the bottom which is the same approach we're going to try and take with this terms of use one discussed today.
... Those are the PRs we need feedback from the group on. Let me ask right now -- does anything on there seem like someone might object to it? You are very concerned about the PR and you will provide negative feedback.
... Ok, so barring any feedback before Sat/Sun of next week we will merge.
... As for the instant run off vote I'll send something to the mailing list. We'll hold that open for a couple of days to get people into a Google doc and then do an instant run off vote for people in the working group.

<DavidC> #229 is to be deleted. Is this correct?

stonematt: Will you hold that open through the holidays?

manu: We'll start the vote right after the holidays. Put them in before Monday -- we'll call the vote on Monday and it will close on Friday.
... And the winner will be what we call it.

stonematt: 5 minutes to go. Any other PRs to hit?

manu: Nope.

DavidC: It was to clarify that #229 will be deleted?

manu: 229 will be deleted/closed.
... I have to look again -- I need to talk with Chris Webber if he's ok with it being deleted outright. He'll do a diff and confirm.
... We'll keep that open for now.

DavidC: Ok.

stonematt: Thanks everyone, good discussion today. We're at time, no other business, adjourn!

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/They/The 8 steps/
Present: Tzviya_Siegman DavidC Kaz_Ashimura David_Chadwick Ken_Ebert Yancy_Ribbens Matt_Stone Dave_Longley Manu_Sporny Ganesh_Annan Dmitri_Zagidulin Brent_Zundel Ted_Thibodeau JoeAndrieu Joe_Andrieu
Regrets: Dan_Burnett
Found ScribeNick: dlongley
Inferring Scribes: dlongley

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: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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.)