<burn> scribenick: JoeAndrieu
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
<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
<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.
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.)[End of scribe.perl diagnostic output]