<brent> scribenick: brent

Agenda

stonematt: simple agenda today
... some conversation about anonymous presentations
... any additions or changes?
... anyone new on the line? Jonathon Holt?

Introductions / Re-Introductions

jonathan: clinical geneticist by training. work closely with the infamous Johnny Crunch

stonematt: anyone else new?

Sercank: Greg Nutley asked me to sit in today. from <someplace awesome>.

Issues and PRs

stonematt: unassigned issues? there are none that aren't deferred.
... discussion today around PRs in flight. but before that, we have a number of issues that don't have PRs

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

stonematt: open issues not deferred.
... couple things to point out, the ones labelled CR-Blocker are the highest priority.
... last week we added CRExit Blocker, these need to be resolved before we exit CR
... also some horizontal review and editorial issues.
... most critical are CR-Clockers
... these need to have a PR pending

<stonematt> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3ACR-blocker

manu: can we go in opposite order?
... just going over CR-BLockers and see where we're blocked.
... a number of these are blocked waiting for feedback.
... is the person assigned going to do something, or do we close these?
... is that okay with the chairs?

stonematt: yes

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

manu: 222, Coordinate with PING

<Zakim> manu, you wanted to summarize all CR blockers.

<dlongley> brent: So this is unrelated to the ZKP stuff, this is to write something into the privacy considerations section regarding private browsing. I was going to ask for a copy of feedback from PING about private browsing on the call today so I could use that to move forward on this?

DavidC: that would be in the PING meeting minutes when they discussed this
... we went to their group meeting.
... don't believe we ever got anything else.

<Zakim> manu, you wanted to specify what to write.

manu: they were concerned about what would happen when a credential exchange happens in private browsing mode.
... or make sure the person is warned very thoroughly.

brent: got it.

<dlongley> brent: Most likely it will be by the end of this week.

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

brent: PR by the end of the week.

manu: security vocab locations

<manu> https://github.com/w3c/vc-data-model/issues/391#issuecomment-469668035

manu: we need to acquire authorization for a security vocabulary directory, this is all on kaz.
... chairs, please ping kaz to make sure this happens.

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

manu: new is 413, Dan this is on you

<Zakim> burn, you wanted to reply

manu: please review the conformance section. I believe it is being interpreted as talking about issuers and verifiers.

burn: the section on conforming processor, plus section 7. I believe this is outside of the scope of our spec
... but I am going to drop it for this issue. If it comes up again during testing and CR review, I will request the sections be removed.
... if is shows up again during the CR review time period, I will request they be removed or changed.

stonematt: kaz is online

manu: I raised a new issue on section 7 saying that it still has untestable statements.
... does that address your concerns about "conforming processor"

burn: personally, I think that is weasel wording. any comments on processing are outside the scope of the data model.
... if the section is marked non-normative. we need to make statements about a conforming processor

manu: I will take this and make those changes. please review the PR to make sure I did what you just said.

<dlongley> "We expect that a conforming processor will"

burn: "it is expected that a conforming processor will ... "

manu: we can make that change

burn: make that non-normative as well.

<manu> Make sentence about conforming processor non-normative

manu: that's that issue.

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

manu: zkp section needs corrections.
... I need to review that and Ken
... there is a PR.

ken: on the previous issue, please let me and rhiaro know when those are in, we are responsible for reviewing the conforming language
... also I have reviewed the zkp PR.

stonematt: ken, you may have an invite somewhere from kaz to allow us to assign you.

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

manu: going back to the one we previously discussed, issue 391. kaz, we need a location for the security vocab.

kaz: been talking with webmaster. they'd like to manage all redirection requests. I'm now talking with them and asking them to create the directory for this purpose.

manu: can the chairs contact the system team?

kaz: no, the team contact needs to do it.

manu: this needs to happen very soon. when we do, let me or Dave Longley know so we can transfer contents

kaz: sorry for the delay

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

manu: next one is related. issue 427. We don't have the file published, etc.
... both issues are the need to have things published at the w3c.

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

manu: issue 432. This is waiting on a PR from DavidC.

DavidC: this has been incorporated into the conformance PR.

manu: okay, we'll double check that.

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

manu: next one is a big one, can we timebox 10 minutes around this for discussion?

stonematt: I will start the clock.

manu: we can't close this issue until the PR is in.
... brent has raised a number of issues around untestability. We're trying to find the right level of language lawyering to get the stuff in and close these issues.
... what we are trying to get to is conformance statements around issuer and issuance date, things that are required.

<ken> I found and accepted Kaz's invitation.

manu: when they are specified, they must be specified in a certain way

thanks dave

<scribe> scribenick: dlongley

<DavidC> We are saying that X MUST be presents and X MUST contain .....

manu: Do you agree for the things that are required we can have conformance statements?

brent: Yes, totally agree.

<ken> +1

manu: Ok, that's the first thing, we're on the same page there. The second is a little more tricky.
... Philosophically, what we're trying to say is that we'd really like it if you're going to express something optional, we'd really like you to express it this way. The problem with that is that they can express it another way because it's an open world processor and a processor can't detect that.
... If they are using something like "myIssuanceDate" we can't test for that. David, do you remember one of these optional things?

DavidC: Terms of Use would be a good example of that, you don't have to have them, but if you do you should use it.

<DavidC> we are saying that optional items are MAY be included but if it is there is MUST contain ...

manu: Right, if you do include it, you must include its type, for example.
... Philosophically, are you ok with attempting to say "If you are going to express it, do it this way"?

brent: I don't have a problem with that. So the problem came up for me when ... we attempt to say, "If a conforming VC must express the date that the VC was issued using the date property". That statement is untestable.
... It's testable to say that the issuanceDate property must be present or that the expected use is to be the date or the date value MUST be an RFCxxxx whatever. Those are testable.

<burn> Brent is correct

brent: I cringe when we try to require conformance to intention.

<burn> mandating how/when to use is a problem. mandating format when used is acceptable.

manu: It's clear. I'm trying to figure out a way of basically saying... the testable portion is to make sure that they at least use the field. They aren't taking the field, deleting it and changing it to something else. It's fine to express issuanceDate in your own way, but if you are given a protocredential you have to preserve it.
... You can't override or delete it. I know that that is a bit of a difficult ... I think that's testable. If you have an input file you can't remove those things.

jonathan: On the flight back I had an epiphany on the interplay. With VC+JSON these things are mandated ... we conform on application/json and in that form, in that transformation we have to have things in a full format including scheme definitions. When you use JWT it serializes and is implicit in the specification. A lot of the spec is readable for JSON, it's human readable but it gets lost in translation when we transform it from one MIME type to

another.

brent: What we need to be able to say is "this property must be included" and we can say that the expected value of this property must be a URL, but what we can't say is that type information must be expressed using the type property. You can say you have to have a type property and it must be a URL and here are the objects that must have a type specified, but you can't say how it must be used.

<burn> +1 brent. mandating how/when to use is a problem. mandating format when used is acceptable.

brent: That's protocol and a level above what we can talk about and it's not testable from a data model perspective.

<burn> yes, can say "must be present" and "must contain". it's "must mean" that we can't do.

DavidC: I actually disagree with Brent there. We can say that the type must be there and it must contain a URI. We can't mandate that the URI is correct but that it must be one. What I've done is suggest some wording in the chat minutes. If we agree this must be present and it must contain -- two musts -- for something like terms of use it may be present but it must contain. The only hole we've got in that is that it may be present. We can't stop others

from using another way to express terms of use.

DavidC: But if they do specify our terms of use they have to do it the right way.

brent: I would go a step further, we can't even say it for the required fields -- we can't say they must be used in a certain way.

DavidC: I think we can.

<Zakim> TallTed, you wanted to say "you can't do xyz" is PROTOCOL

<burn> +1 Ted

<brent> +1 Ted

<stonematt> +1 TallTed

TallTed: We absolutely cannot say "you cannot use this in this way". That is protocol, use, that is action. This field must be present, the values must be that, fine, great. We can't say "if you see this field you have to use it like this" or "if you see this field and translate it this way this must be your result" except possibly between serializations.

<brent> scribenick: brent

TallTed: I cannot fathom why very intelligent people keep going down these rabbit holes

<Zakim> manu, you wanted to ask brent and DavidC to work it out in the PR :) -- with concrete language. and to

TallTed: we are nowhere near solid enough

manu: Brent, David, please figure this out in the PR

<DavidC> will do

will do

<DavidC> +1 TallTed

manu: please, very active conversation this week

<burn> Brent and Ted are correct. This is not an opinion. This is reality.

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

manu: 444 is simple PR. we have wide buy in. I will do a PR for that.
... this may be part of the big PR as well. 443.

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

manu: I will take it and do that PR
... next is 446. I re-read section 7 in depth. it has conformance statements that need to be cleaned up.
... we could take care of all of these this week.

Brent and David need to get together on this.

manu: I can go in editorially afterwards

DavidC: what about the proof being mandatory in one part of the spec and not another?

manu: if that is still an issue, please raise it.

burn: brent and ted are correct. this is not opinion. we have let the group go on and one. we are at the point where if there ends up being a dispute again.
... I will defend that to the director of w3c. I hate being arbitrary, but this has got to stop.

<manu> me :)

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

stonematt: feature request. anonymous presentations
... we had a feature freeze last fall, nothing to add to the spec now.

<brent> +1

<burn> +1 manu

manu: we are not preventing this in the future. the data model should support this in the future

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

stonematt: manu anything to add to PR review?

manu: jonathan good thing you're on the call. I would like to drop the IPLD PR, based on what we discussed in Barcelona. Would you object to that?

jonathan: I will close it and re-open it so it is more clearly about CBOR.
... we're settling on JSON because it is more human readable.
... this is where the MIME types would be really useful.

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

jonathan: behind the scenes IPLD is CBOR. So I will re-submit as CBOR and give a JSON serialization of it.

manu: will review ZKP
... brent and David C, please get together on the conformance PR
... the one from Grant is editorial

stonematt: covered a ton, thank you

<Zakim> burn, you wanted to explain that chairs marked ipld as defer as a new feature request

burn: the ipld PR was marked as defer and feature request. we will look at what you send in, but we are not going to add any new syntaxes and formats.
... as long as you are not prevented from doing what you need, that can be added in the future.

jonathan: as long as we can all agree on the JSON, we can serialize that as we need to

stonematt: no other business. thanks for your focus and work to get this done.

<stonematt> thanks all

<kaz> [adjourned]