<burn> scribenick: JoeAndrieu

1-Agenda review, Introductions, Re-introductions

burnett: agenda: action items, unassigned issues, then the major topic: issue 158
... if we have extra time, we can look at machine readable terms of use

2-Action Item Review

<burn> https://goo.gl/V4XTBT

burnett: four outstanding action items

manu: re "Verifiable Profile" & #29. I'm happy to pick those up

burnett: the point of this is just to keep track.
... until we get to an issue or PR

manu: 25 has an issue, 29 doesn't

burnett: ok. so line 29 is still open
... line 30. next

line 25 is issue 163

<dlongley> https://github.com/w3c/vc-data-model/issues/163

burnett: any chance for you two to talk?
... Could you reach out to Chris?

Row 32

<manu> I just assigned https://github.com/w3c/vc-data-model/issues/168 to me - to reword Ecosystem description/expectations.

scribe: Row 32 is pending the discussion of the third use case

3-Assign owners to unassigned issues

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

scribe: we might have zero unassigned issues

<manu> What about this one? https://github.com/w3c/vc-data-model/issues/133

scribe: yep. nothing to do here, today.

manu: what about 133?

burnett: assigned to David
... this may have been assigned when we were having issues with Joe's account
... Issue 98: Just closed
... Issue 80: deferred
... Issue 57: Ideas for roles to add for data model for next draft
... This is kind of old.

<manu> +1 to defer and ask Richard Varn what he wants to do about this

burnett: Suggest that we defer rather than just close it. I will try to reach Richard and see if there is anything that he would still like us to consider.
... Any objections?

stone: not here

burnett: That's on me.

<burn> ACTION: Burnett to reach out to Varn regarding issue 57 status

burnett: ok. That's all the unassigned issues.

4-Issue 158/PR 159/etc

burnett: the big item for today
... I didn't want to put a name on this. Issue 158 and a PR

<burn> https://github.com/w3c/vc-data-model/pull/159

<Zakim> manu, you wanted to try to attempt to explain how we got here

manu: At the f2f, there was a discussion about handling extensibility
... the consensus was that we need to explain how extensibility works for VC data model spec
... we hadn't done it before, because we assumed knowledge of JSON-LD
... that wasn't working.
... There is a section that Manu wrote up in a PR, loosely how extensibility works.
... meant to be a non-normative section: just explaining
... that PR went in, then David C raised a bunch of good points
... there are concerns: how do you state that a feature is critical
... So I opened a new issue for Critical Points
... Manu pulled in the PR just about when David brought up issues
... Must a verifier reject a claim with a section they don't understand?
... So... the first PR was pulled in.

burn: do you have the numbers?

<manu> This PR added the extensibility section: https://github.com/w3c/vc-data-model/pull/159

manu: so, PR 159. This added the extensibility section
... clearly there some disagreement about it
... that resulted in raising issue 158

<manu> Critical property field was raised here: https://github.com/w3c/vc-data-model/issues/158

critical property field

scribe: 159 is *in* the spec
... we could revert that
... then there is a question about what should a verifier do in the event it doesn't understand something in the verifiable credential

1. should we revert the new section until we figure this out?

2. should we leave it in, then talk about it?

3. Some other option

dlongly: I'd rather not revert.
... we've got something now we can debate and talk about.
... reverting it would take up time and effort and cost us that framework for discussion

davidc: that's a great summary. I'm unhappy with the text (a) it is inconsistent and (b) already pre-judges the extensibility

burnett: audio check.

davidc: how is it now

burnett: whatever you just did is better

stone: me too. that's much better

burnett: ok. what's a viable resolution?

davidc: I would like to propose a resolution
... There seems to be resolution that there will be no flag
... if Verifiers receive anything they don't understand, they should reject it
... My concern is that this will limit adoptability
... But if people are happy to say the Verifier MUST reject anything they don't understand

burnett: any other opinions?

<Zakim> JoeAndrieu, you wanted to talk about claims

<Zakim> manu, you wanted to raise the "revert" question -- if we add "verifier MUST understand and throw", is that okay for now.

<stonematt> +1

<dlongley> JoeAndrieu: What I recall from previous conversations but didn't hear here was potential distinction between top-level terms in the graph and what's in claims. I feel strongly that issuer should be able to say anything even if not fully understood.

manu: agreed we don't have closure on that, Joe
... Let's break these into smaller issues.

<stonematt> +1 to extensibility focused in the claim and somewhat limited (maybe very limited) in the "envelopes" of credential and profile

manu: First: are we reverting or not
... if we put it spec text that if we switch to MUST, we can keep the rest of the PR
... but that doesn't address the other issues
... if we put in that text, "verifier MUST understand or throw"
... would that be enough to keep it?

davidc: it's not just a sentence. there might be a number of edits to be made

manu: yep. I'll make a pass towards this goal.
... in another PR

burnett: ok. sounds like we have a path forward.
... so what would be an appropriate time to discuss the other issues

manu: NOW
... so let's just start talking about them

burnett: should be just create some place holder issues?

manu: we have an issue for one of them: the extensibility one

<manu> ACTION: Manu to submit PR to say that Verifiers MUST throw if they don't understand content in a PR.

stonematt: I was going to invite... it seems like there are a couple of items in play that we need to do discussion on
... so let's queue up the important one so we can keep the chat bounded

davidc: if we've agreed on this "must" language, then there's no need for critical properties field
... the reason for the field is so you can mark what is important. but if the language is "must" we don't need it.

<Zakim> manu, you wanted to talk about Critical Properties.

manu: right. so there may be a misunderstanding about why we are adding the text
... the text is so we can keep the PR, and have more conversation to figure it out
... for example, we've had a bunch of educational VCs.
... because of how the wording of this PR
... these educational VCs have huge amounts of data
... which means its a huge burden on the verifier
... which results in the spec deviating, because people ARE going to ignore the MUST throw an exception part.
... selectively
... So that's the concern about the approach.
... In many cases, its better to accept the credential, then to throw the exception
... there are many that might provide an email address.
... if I know that email exists in a credential, that may be all I'm interested in
... but the suggested PR would mean that verifiers would have to throw if they don't understand EVERYTHING else

davidc: I addressed this in my comments to the PR:
... if implementers want to be non-conformant, that's fine
... but if someone wants to make sure, then he needs to conform to the spec
... you can conform or not

dlongley: SHOULD is something that is typically used in this situation instead of MUST

<Zakim> manu, you wanted to note why MUSTs are dangerous

manu: not to continue beating this horse....
... there is something that's been emerging at W3C:
... if a spec ignores reality, that's a bad spec
... if the fact on the ground is that most people are going to be non-conformant
... that will lead to an "academic" version of the spec that nobody actually fully impements
... if we use SHOULD instead, that allows us to provide guidance
... aligned with Dave Longley's "monotonic" approach to data minimization

<dlongley> we can also recommend that issuers should create VCs that use monotonic logic (claims don't invalidate other claims made in the same VC)

manu: therefore the credentials--in general--will be smaller rather than monolithic
... it also fits DavidC's desire: you really should understand this. You SHOULD.
... This addresses everyone's concerns

davidc: the problem I see with this is the problem we have with x.509
... when systems accept invalid certs
... but if we're building software that is protecting access to important resources
... we don't want to say you're conformant if you use credentials you really don't understand
... I fear we'll weaken the whole infrastructure, with access inappropriately given

dlongley: I don't think that moving MUST to SHOULD or vice-versa will address those issues.
... the problem with X.509 isn't going to resolve how people are actually going to use the technology
... including why it is a SHOULD

benjamain_young: the user pain point needs to be considered

<TallTed> sometimes you really do have to say "This SHOULD SHOULD be a MUST".

benjamain_young: so I support the SHOULD, as people will adjust happy before security, so its only those systems that map security to happy that works
... if you're too academic, it lessens the security
... if we make it too hard to be secure, they'll just go the other way

<dlongley> +1 to overly prescriptive specs pushing users to a path of least resistance ... tricky balance.

burnett: this may be the path we need to take
... but I'm always hesitant to use SHOULD instead of MUST
... if you give a should you are expected to explain when NOT to do it
... SHOULD, UNLESS really
... and if you have an UNLESS, you can use MUST, UNLESS

tallted: past experience has shown that a good way to go is to make it "switchable" and advocate for the better, but to allow for the possibility that deployments may not be able to do that
... so they can switch it, but the OUGHT to leave it on.

<Zakim> manu, you wanted to note another insight -- if the verifier is asking a question that the issuer didn't know about, that's when this rule will be broken.

tallted: so instead of MUST behave X,Y,Z, implementers must have a way to implement X,Y,Z

manu: something that helped me: One of the things we are presuming is that both the issuer and verifier know what the question that is asked.

<burn> +1 to switchable, with default of strict

manu: Verifier asks "Are they married" Issuer can just answer the question.
... But because of credentials, we have an asymmetric situation
... the verifier is going to ask may be unanticipated by issuers.
... So the issuer a more broad set of data, which is where the problem is
... there are use cases where a verifier is willing to accept parts of such a license without needing to understand the state-specific customizations

<bigbluehat> +1 to nuance

davidc: I think there's a big difference between a degree and an atomic credential
... this is where you can say MUST, UNLESS.
... you MUST reject if you don't understand and you're protecting resources with it, BUT in the following situations its ok

<nage> +1 data meaning changes over time and even if specific context isn't understood the entirety of the credential can often still be understood. When doing ZKP-style credentials there is less reason to boil them down to these micro-credentials, because minimization is handled by the holder more than by the issuer (this allows the issuer to worry less about how the credential may/may not be used).

davidc: if we put that in, that may address concerns

<Zakim> manu, you wanted to propose something -- any objections to SHOULD? or if MUST, unless (then what do we follow it up with)?

burn: trying to wrap up

manu: I'm still unsure where the group is.
... any objections to using SHOULD?
... if MUST, UNLESS makes sense, then what is the UNLESS section?

<DavidC> Yes

<bigbluehat> +1 to SHOULD because UNLESS seems untestable...

manu: are there any principled objections to should

<DavidC> Yes I object to should

burnett: there's always an UNLESS with SHOULD (its implicit even if unstated)

manu: so what's the UNLESS?
... that's the question

<DavidC> We need to spend some time thinking about the Unless content

<TallTed> +1 object to SHOULD without the requirement to enable the wanna-be MUST

burnett: those note on IRC: there's a lot of back and forth

manu: at this point we're not going to resolve this.

<DavidC> +1

<nage> +1

<TallTed> +1

<stonematt> +1

manu: I'll put a MUST in the spec
... any objections

burnett: agreed

davidc: the conformance testing will only be on MUSTs, not SHOULDs

manu: SHOULDs are tested too

davidc: the other week we shouldn't

bigbluehat: SHOULDs have to be tested, but not don't need to be implemented

<manu> I'll put something to the effect of "a Verifier MUST throw an error if it does not completely understand the semantics of the verifiable credential"

<burn> And we will continue discussion in github

I've got to bounce

<burn> Just want the minutes to be clear that there is not agreement on this

<nage> Disclosure is in the hands of the Holder, not the Issuer, so isn't that by design? The holder and verifier can decide to use a credential against the issuers wishes (just like your student ID card is accepted for a discount at a sandwich shop).

<manu> scribe: manu

burn: I'd like to make sure the minutes are clear that there is not agreement on this topic.
... I don't think we have enough time to start on another topic, need more offline discussion.
... AOB?

stonematt: Queue up discussion for next week -- in github, working on milestone Subject != Holder, we've moved on, haven't we? Maybe we work on critical properties / terms of use?
... I'd like to decide where we are on that roadmap next week.

DavidC: I wasn't aware that Subject != Holder is resolved.

burn: There are 3 PRs on subject != holder outstanding, you need to take a look at those.

<burn> ACTION: David Chadwick to review existing PRs

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/issue 63/issue 163/
Succeeded: s/Issue 58/Issue 158/
Succeeded: s/No problem//
Succeeded: s/options/opinions/
Present: Allen_Brown Benjamin_Young Dan_Burnett Dave_Longley David_Chadwick David_Lehn Joe_Andrieu Kim_Hamilton_Duffy Manu_Sporny Matt_Stone Nathan_George Ted_Thibodeau Tzviya_Siegman
Found ScribeNick: JoeAndrieu
Found Scribe: manu
Inferring ScribeNick: manu
ScribeNicks: JoeAndrieu, manu
Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2018Apr/0025.html

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: burnett chadwick david manu

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