- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 17 Jul 2019 16:21:07 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/07/16-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Oliver, Amy and Ganesh!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
16 Jul 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Jul/0006.html
Attendees
Present
Daniel_Burnett, Tzviya_Siegman, Ted_Thibodeau, Amy_Guy,
David_Chadwick, Justin_Richer, Manu_Sporny, Matt_Stone,
Dmitri_Zagidulin, Dave_Longley, Oliver_Terbu,
Brent_Zundel, Jonathan_Holt, Benjamin_Young,
Allen_Brown, Ken_Ebert, Ganesh_Annan, Yancy_Ribbens,
Kaz_Ashimura, Kaliya_Young
Regrets
Chair
Dan_Burnett, Matt_Stone
Scribe
Oliver, Amy, Ganesh
Contents
* [3]Topics
1. [4]Describe plan for the call
2. [5]Update from call with Director
3. [6]iat/nbf discussion
4. [7]Implicit Typing
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<scribe> scribenick: oliver
Describe plan for the call
burn: the plan for today is pretty much the same as for last
week
... Andrei is not here today, so we are not discussing
implemention guide because he is not here today
Update from call with Director
burn: next item on the agenda
... we had a call, the chairs and manu, with w3c director last
week
manu: mostly, we had a couple of questions, first iat/nbf issue
... he suggested a way around it which we tried to exeute on
over the past few days
... second one, type discussion where that has been going in
ways where we can resolve that
... it is considered to be bad on formal objections
... only if the group sees no way forward, we should raise
formal objections to the director
... request primarily was to figure out in the group first
... what we need to do on the call today is what we do with
iat/nbf
... we should talk about that first as it is not as
controversial as the type thing
... these are the two things between us getting a standard out
... we should skip all other PRs as they are editorial
<manu> [10]https://github.com/w3c/vc-data-model/pulls
[10] https://github.com/w3c/vc-data-model/pulls
burn: agree, all other are minor looking
<manu> These are all editorial, except for the two ones that
are problematic.... iat/nbf and types.
burn: we should talk about the significant two PRs
manu: if there are no objections, let's pick the iat/nbf first
iat/nbf discussion
no objections
<manu> [11]https://github.com/w3c/vc-data-model/pull/668
[11] https://github.com/w3c/vc-data-model/pull/668
<rhiaro> scribenick: rhiaro
oliver: when the final version of the test suite got merged it
never had the iat, had the nbf
jonathan_holt: is the PR misnamed? in the PR nbf is in addition
to iat. You can't have it issued and not be valid according to
the JWT spec
... is it really a replacement semantically?
manu: if oliver's PR added something normative that would be
another CR. If he was changing soemthing that implementers had
implemented before the change, that would be another CR
oliver: as far as I remember we first updated the PR of the
test suite and then test suite got merged and contained the nbf
for the final version of the test suite, it was never checking
the iat field. I agree with jonathan that nbf and iat, it's no
contradiction to use both. According to the JWT spec and JOSE
attributes the semantics of iat is copmletely different
... I would have expected implementers to be aware of that and
use iat to express the current date of issue and the natural
way of doing this is to use nbf to specify to express the not
valid until. The w3c spec was in contradiction to the JWt
specification. Was definitely a bug
manu: bugs are CR-triggering things
... It may have been the natural thing to do for some
implementers but we have two examples of implementers who
implemented per the spec, and that was the wrong thing to do
... that is the position of the director
... The test suite is not a normative thing. It's something we
provide people but the normative thing is the spec
... THE thing that has to survive CR without bugfixes and
substantative changes
... Two implementations need to be updated we know about. The
concern is there would be others we don't know about
burn: If I were going to explain this was okay my statement
would be that the people who know what they're doing with JWT
would naturally implement it the correct way and would be
surprised to find the spec said something different, and would
do what oliver did fore xample
... for people who implemented it naively, who aren't familiar
with what it's for, in that case I could say that the people
who did that as soon as they ran it against the test suite they
realised there was a problem and then they fixed it
... however I am mentally prepared for this to trigger a CR
because the rationale is that, say you go from CR to PR, if
there isn't a warning (a new CR) then the expectation of
someone who reads the PR is that nothing important in their
implementation had to change from when the CR was published
... It could be that they misunderstood something. We don't
know how someone might have implemented incorrectly, so it's
more that aside from clarificatiosn on what we meant, no
changes would be required to an implementation
... Using that definition, this is a substantive change
<TallTed> I see no good way around the fast-track minimal
iat/nbf CR#2, in parallel with PR transition process.
<burn> For the record, I am not worried about the implementer
in the woods. I don't think they are out there. I also agree
with David that any random implementer out there would have
checked against the test suite.
DavidC: I'm concerned about this implementer out in th ewoods
somewhere because whatever we do is not going to affect what
they do, therefore I don't see why it should affect why we go
to CR or PR. If they have an implementation and they want it to
work they need to run it against the test suite. The minute
they do that they find the bug. I don't see how there could be
someone out there who has implemented wrongly and hasn't tested
it. This person
surely doesn't exist
manu: this has happened before with the JSON-LD spec.
Implementers don't run things against the test suite if they
don't want to support the whole spec
<Zakim> TallTed, you wanted to say these tests didn't exist
incorrectly; PR was created with iat and edited to nbf before
merge
TallTed: for history's sake, the test suite never existed with
the incorrect test, that is true.
... The PR was submitted with the incorrect test but it was
corrected before merge. Tested run before merge did not test
these aspects of JWT translation
... Yes you passed but it wasn't testing this thing
... I am also seeing no way around the fast track minimal fix
this definite bug, typo, no question, anyone who is experienced
would do the right thing, but unfortunatelyt he spec is not
written for someone who is experienced in everything involved
... the test suite not being available when the CR went out
means we really can't point to it
oliver: I agree with that
... Isn't it the case the test suite report should only be
valid when testing against the final test suite? Not against
PRs? They would have to be rerun
TallTed: yes, preliminary tests are informative to the test
suite devs. The spec is the governing factor. If you fail a
test you go back and say the spec said this and the test did
that. The spec is the thing in control, the test suite would be
incorrect
DavidC: My student tells me he didn't run any tests with iat,
all the tests he ran were with nbf
<Zakim> manu, you wanted to propose a path forward.
manu: The only thing that would save us at this point is if
markus also said he looked at the spec and saw iat but
implemented nbf anyway because that was the right thing to do
... the point we're at is to issue another CR, very tight
turnaround. We can explain this is a very fine line and we
don't think goign through another CR is going to impact
implementers who are doing the right thing. We don't think
there are any bad implementations out in the wild. And hope
that the director agrees the group has done everything to reach
out and you know all the people who have implemented it, then
we can go straight to PR. If he
... says no we need to go to CR, then we'll trigger another 28
day turnaround with this as the only substantive change and the
only feature we're requesting feedback on, and then we'll try
to get an emergency call with the director this week, processes
all of the PRs and try to get a CR published asap and then
parallel track the PR
... The PR will assume this change is going to go through and
can be published shortly thereafter or on the same day the CR
ends
... Would anyone object to that approach?
burn: the director also said nobody wants to issue a spec with
a bug, and they also don't want w3c process to kill this in
this case where it is highly unlikely that there is an
implementation in the wild for which this would be a problem.
They're going to try to find a way to make it work even if we
have to do this special issue CR
manu: As another data point, this is one of the reasons we
tried to get the DID test suite out there now is to avoid what
is happeneing now, that there is a bug in the spec and the test
suite didn't catch it early enough
<scribe> scribenick: oliver
Implicit Typing
<manu> [12]https://github.com/w3c/vc-data-model/issues/682
[12] https://github.com/w3c/vc-data-model/issues/682
manu: before we jump into this discussion
... i want to clarify
... all of us are arguing for the same thing
... what we are arguing about here
... is the amount of detail what we do
... pls feel free to correct me
... implicit typing was always done
... but we were so vague that
<DavidC> I actually disagree with that statement
manu: disagreement is not a vs b but how detailed we want to be
about a
... some say let's keep it vague
... not figure it out until PR
... put in impl guide
... other say we need to spell out how implicit typing works in
the spec
... that is more or less where the convo is
... on top of that always happens, this type of discussion,
there is always the last issue that the group has to close and
is always controversial thing
... we really have to try hard to compromise and come to
consensus during this discussion
... if we cannot achieve that then it is going to a director's
decision
... we might not have time to figure that out
burn: thi sis normal for working groups
... and i have been in different ones than manu
... we all have to work towards our endgoal
... we were just talking about making a special issuance CR
... we need to keep that absolutely minimal as possible
... still complaints from ppl who have objections
... we don't want to open this CR to these ppl
DavidC: this issue was explicitly introduced in june
... it was not explicitly articulated and it was not in the doc
... the doc has not outlined the steps that we took
... i agree we want to get to PR, don't agree that implicit
type was ever in the CR
<Zakim> TallTed, you wanted to ask about "top level properties"
-- precise definition may help to resolve this more quickly
DavidC: i am happy to keep implicit in but in a controlled
manner
TallTed: my question is about the part that david has
highlighted which is the top level property
... which forces the secondary type
... i am not sure what you mean by a top level property
... is it something that describes the credential
... or something that is contained in the cred
DavidC: currently, we specify everytrhing what a credential can
contain
... all the properties
... every property has a type which is mandatory
<DavidC> oliver property->object
<DavidC> oliver every object has a type
<Zakim> manu, you wanted to make the argument for "implicit was
always in there" and point to spec text.
manu: the reason that i said implicit was always in there
... and i agree wth david that it was not clearly stated
... some of us have been involved with the linked data world
for a very long time, graph based data model for a long time
... in that world, there were many ways to dertmine the type of
an object
... first, we really need to make the type mandaotry but in my
head
... i can see that ppl who not come from the world, need that
... fundamentally it was not a harmful thing
<manu>
[13]https://www.w3.org/TR/verifiable-claims-data-model/#types
[13] https://www.w3.org/TR/verifiable-claims-data-model/#types
manu: this PR says whethere the spec said it before or
something new
<manu> "All credentials, presentations, and encapsulated
objects MUST specify, or be associated with"
manu: that or be associated with means something specific to
linked data community
... something associated with a type
... now i am gonna list them
... in some cases, you don't need type at all
<dlongley> the definition of the SSN property can say "the
domain of this property is Person"
manu: determining the type, you can look at the proeprty and
know what that thing is associated with
... properties can be directly mapped to types
... in some cases it you could say it is abosolutely implicit
... in the json-ld world, when you specify the context,
... those things have to map the properties that you have in
the document
... if you have a context mechanism, then you don't need type
... when you add another property, then you have to add another
context
... then you don't need the typing stuff
... becaue the app knows how to deal with that stuff
... i am disagreeing that implicit was not in there in the spec
... the thing is missing that you are not coming from the
linked data space
... it is a language issue
... and the language led to confusion
... but there is abosolutly a way to read the spec where
implicit typing is in the spec
<Zakim> burn, you wanted to check on DavidC/TallTed when Manu
is done and to summarize Manu that if you are a JSON-LD person
you will understand "be associated with" to mean "implicit
manu: which was the intention i wrote the spec
<dlongley> +1 to the above
burn: if you are a json-ld person, then you would believe that
implicit type aws in the spec
... if you are used to json-ld
... other comment
... david chadwick and tallted, if either of you have questions
that i brought up, requeue
jonathan_holt: this really requires json-ld processing, in
barcelona we agreed that context was required, but processing
it, was not
DavidC: when you read the very next sentence, then you will
find the definition what associate meant
... and that object does not have a type
... it did'nt have the implications that you thought about
... from the start of this WG, what about if ppl don't
understand json-ld
... it was yes, they are perfectly fine with json
... the very next sentence defines what associates means...
... that was the first point
... if you had a new property, then you have to add a new
context
... but that is not true
... it is not actually correct what you are saying for that
reason
ken: also commented, not coming from a json-ld background
... it was confusing for me first
... after the first discussion, i figured there were additional
ways to define type
... my conclusion is to allow either way, explitic and implicit
... and it would satisfy the needs of multiple communities
<brentz> +1
ken: so i was happy to have either explicit or implicit
<Zakim> manu, you wanted to say it DOES NOT require JSON-LD
processing. and to address "very next sentence" bit
manu: two things ...
... first jonathan, that does not require json-ld processing
... you don't have to need a json-ld processor for implicit
typing
... you could ignore the whole json-ld syntax
... when two systems are communicating, they need to establish
context
... not necessarily json-ld context
... it is like french
... both have to speak french
... even a json developer has to specifiy the context of the
communication
... they have to define the vocabularies they are using to
establish the communication
... @context does that
... if we had not json-ld, then woiuld have something else
... it is not a json-ld thing, it is a data semantics thing
... you don't need a json-ld processor for implicit typing to
work
... json developers are stealing @context from json-ld to set
the appropriate context and with that you could do all types of
explicit and implicit typing
... you have to pay attention to the context
... you don't need to do that but when you do that you are
typing implicitly
... if ppl are coming from a pure json background, it is an
information semantics thing
<Zakim> burn, you wanted to ask that we not tell other people
what they think the spec meant; they know themselves
<Zakim> brentz, you wanted to say it is not a definition, it is
an example
<dlongley> JSON has context, it's just not formalized in
anything other than a human readable spec... (you have to hard
code to your applications to it) ... all `@context` does is
make it machine readable.
brentz: there seems to be two ways forward
... either we remove the sentence about the implicit types are
allowed
... we remove the claritiy that it introduces to the spec
... and allow future impl to check is implicit typing required
or not
... or we could make this clarification and move forward
... the fact that both sides are the reading the same text but
iinterpreting it differently, is a sign to clarifiy the spec
davidc: i agree clarification is needed and i agree it is a
information semantics thing
... i wanted to define what is the different between an open
and a closed / proprietary standard
... a closed is a subset of ppl which don't want to let know
the world what it is
... an open standard that should be open, a msg should be given
to every single entity in the world
... and this is what the VC system is about
... to allow the verifier to know what they are getting
jonathan_holt: one concern..
... lack of semantics interop
... to extend the argument that i see in the issue
... when switching to a new system, then we lost the semantics
of the meaning of that
<TallTed> Nothing in this spec says that every
recipient/verifier must be able to fully understand every VC
they receive. VCs that are not understood should simply be
rejected. (A Russian driver's license need not be accepted by a
US police officer. An *international* driver's license must be
accepted by a US police officer. Both are meant to be VCs.)
jonathan_holt: which would potentially cause miscommunication
and implementers won't get it right
<Zakim> manu, you wanted to propose ways forward in addition to
brentz -- non-normative is fine. and to mention that I'm not
hearing disagreement on what we want the outcome to be... maybe
manu: i won't to focus on what brent was stating
... i don't hear disagreement with each other
... i am hearing agreement that we all want to support implicit
typing
... but stop mandating it
<brentz> +1
manu: strong typing is good but we also understand that there
are many other ways for typing
... it feels that we can write some text that we all agree to
which is non normative
... which does not make a subst change to the spec
... and if we can get to that then i hope we won't see any
formal objections
... i want to find out the text which everyone is happy to live
with
... at the same time we need to input to the spec, especially
for ppl outside of the group
... remember we work with a 12 days delta until the end of our
charta
... that is why my suggestion is to move all these discussions
to the implemention guide
... this will allow us to get the specification / language
right
... the other approach would be
... here is one option
... option 1
... we rip everything from spec out, brent's, ted's, david's
and leave it as it is
... understanding that ppl would say it is vague
... option 2:
... we add one or two sentences there which is essentially what
brent and ted added
... essentially saying that implicit typing is ok
... and refer to the implemention guide, put the text in the
implementation guide
... option 3:
... make a normative change
<brentz> -1 to option 3
manu: and wrap that in with the other CR
... personally, i feel that is a bad thing to do
<dlongley> -1 to option 3
manu: but it is an option
<burn> -1 to option 3
<Zakim> TallTed, you wanted to say the above
TallTed: an open standard / spec does not mean that everyone
understands everything
... there a lot of specs that perfectly for private use
<brentz> +1
TallTed: one example, a russian driver's license does not need
to be accepted by US police officer
... an international should
... both are in the world of VCs
... they are not meant to be understood by everyone
... no explicit agreement between a russian dmv and a us police
officer
... explicit text should make it clear what was the intention
of the original text
... that allows more easy entry into the space
... but it should not be forced that way because it prevents
flexibility
... impl guide can also say that these are the hazards of doing
it in this way
<Zakim> burn, you wanted to admin interrupt
TallTed: verifier should define the policy which should be
discussed in the impl guide
<gannan> scribenick: gannan
DavidC: in response to the russian's driver's license, I agree,
that's what I'm arguing for...
<TallTed> he doesn't know it's a russian driver's license! he
knows it's a laminated paper with an unfamiliar alphabet on it!
DavidC: I would like to come back to X.509 and they worked out
that anyone can have a certificate and know what to do with it
... one can accept anything you don't understand
... because the issuer says you don't have to understand it
<burn> Agree with Ted. Don't need to know everything you
receive, just whether it is not something you recognize
<Zakim> manu, you wanted to ask DavidC which one of these
options he could live with?
manu: I want to focus...
... one of the focus of these discussions is we get into design
philosophy
... we may end up not getting to a resolution
... I suggested three options
... I'm requesting other options others we may take
... which option can we live with
... option 1, set back to what we had before to CR
... option 2, add sentences to the implementation guide
<ken> +1 to option 2
<DavidC> option 1.5
manu: option 3, a substantive change
<burn> -1 to option 3, it will bikeshed
DavidC: we can do a option 1.5 where we can add one sentence to
the original CR pointing to the implementation guide
manu: I would be happy if we did that as well
... David would you mind typing the proposal so we can agree
with what you're okay
... with
<manu> PROPOSAL: The Working Group has decided to revert to the
text of the March 19 CR, and in addition we add a sentence
which can be wordsmithed later, but the intention is to say
"typing is complex so we refer readers to the implementation
guide which contains more details.
<Zakim> jonathan_holt, you wanted to ask about how to implement
issuers policies outside of implementation guide
burn: Before asking for approval, any questions?
<TallTed> manu - please be explicit about the section/paragraph
being reverted
jonathan_holt: going back to what Ted was asking about, how
would these policies be managed?
TallTed: these are not issuer policies, these are verifier
policies
jonathan_holt: how do the verifiers know these policies
<burn> Ted has a good point that the proposal needs to be clear
that we are not reverting everything in the doc to March 19,
just some specific text
TallTed: The issuer just issues this thing, and here's the
proof. The verifier verifies the proof and whether or not I
accept this thing
... it's the verifier judgement call
<Zakim> manu, you wanted to get this proposal straw polled
TallTed: out of band communication may happen but it is not a
part of the verifiable credential data model
manu: there has been a modification to the proposal
<manu> PROPOSAL: The Working Group has decided to revert the
type section related to implicit typing to the text of the
March 19 Candidate Recommendation, and in addition we add a
sentence which can be wordsmithed later, but the intention is
to say "typing is complex so we refer readers to the
implementation guide which contains more details".
<gannan> +1
<DavidC> +1
<manu> +1
<TallTed> +1
<dlongley> +1
<burn> +1
<brentz> +1
<ken> +1
<dmitriz> +1
<tzviya> +1
<TallTed> "CR#1 of Marhc 2019" would be sufficient
<bigbluehat> +1
<jonathan_holt> +1
<burn> +1
RESOLUTION: The Working Group has decided to revert the type
section related to implicit typing to the text of the March 28
2019 Candidate Recommendation, and in addition we add a
sentence which can be wordsmithed later, but the intention is
to say "typing is complex so we refer readers to the
implementation guide which contains more details".
manu: does this remove your objection david?
DavidC: yes it does, thank you
manu: we will chase down the iat and ??? with the director
<DavidC> YIPPPEEEE
manu: I know of no other things blocking us from PR
burn: we will need a PR for the specific text for the
implicit/explicit typing
... if we can go to the March 28th sentence on this call, we
can accelerate this process
manu: Where would you like the text to be?
DavidC: We could add a separate note or add it to the existing
note?
manu: I suggest we put it in a separate note as one refers to
type in JSON-LD and the other type will refer to it from an
information science perspectinge
burn: it would be great if we could close this, in this call
<DavidC> haha
DavidC: I would rather say that it's complex, if you could say
"associated types" is complex
<ken> +1
<TallTed> "data, implementers" -> "data. Implementers"
DavidC: That is excellent
<manu> Suggested text is: The type system used in the data
model described in this specification allows for multiple ways
to associate types with data, implementers and authors are
urged to read the section on typing in the Verifiable
Credentials Implementation Guide.
<Zakim> brentz, you wanted to point out there may be other
changes to the type section not related to this issue
manu: let's wordsmith in the PR
<dlongley> +1
<dlongley> (+1 to that suggested text)
brentz: scanning the text in the CR to what exists now, there
are other changes that were put in from previous discussions
that are not related to our current discussion
<manu> +1
<burn> +1 to suggested text
<DavidC> +1
<tzviya> +1 to suggested text
manu: we will not revert those changes
<stonematt> +1 to suggested text
<bigbluehat> +1
<ken> +1 to suggested text
<brentz> +1
<oliver> +1
<gannan> +1 to suggested text
<TallTed> +1 to suggested text modulo sentence break
burn: I see agreement to create the PR with that
... manu will write the PR for the iat and ???
manu: this is an editorial change and we don't need to wait
until next week
... I will work hard to get a PR and CR ready so we can
immediately schedule a transition
burn: out of those three reviews and at least review from
DavidC
manu: of course
<DavidC> thank you
burn: as far as steps go, what you describe sounds like the
right thing to do
... I would like to have a vote to go to CR
... let's plan to do that next Tuesday
... I don't see any reason and get a response from the
director, I see no reason why we can't vote next week to
publish a document
<TallTed> Can email a call-to-vote-by-W3-poll based on text as
of <date>. *Do* email a "we will vote on Tuesday" in any acse.
burn: anyone see a reason why we can't?
<DavidC> +1 TallTed
burn: I will send an email out
<oliver> +1
DavidC: Ted raised the issue that I raised, could we do an
email vote so we can proceed before Tuesday
burn: not comfortable with doing an email vote...
... we have not been doing an email vote
... we would need to have at least a 7 day warning
... I will send an email today warning that there may be a vote
next Tuesday
kaz: I'm just wondering when you want to send the transition
request
burn: It depends on the response from the director
... we had been talking about an early August date
... if it's a CR we want to go as early as possible
... we can't formalize this today
... with respect to other issues and PRs
... issue #222
... we are waiting one of the implementation guide issues to be
complete
... once that is complete, we can close
brentz: the implementation guide PR you are referring to is
ready for review
burn: we can close this main issue once brent's PR is pulled in
<burn> [14]https://github.com/w3c/vc-imp-guide/pull/14
[14] https://github.com/w3c/vc-imp-guide/pull/14
burn: review this and then we can close the implementation
guide issue and the spec issue
... I can review it as I looked at it before
... two approvals now
... issue #526
<burn> [15]https://github.com/w3c/vc-data-model/issues/526
[15] https://github.com/w3c/vc-data-model/issues/526
burn: this is complete
<manu> [16]https://www.w3.org/TR/verifiable-claims-data-model/
[16] https://www.w3.org/TR/verifiable-claims-data-model/
<manu>
[17]https://www.w3.org/TR/2019/CR-vc-data-model-20190328/
[17] https://www.w3.org/TR/2019/CR-vc-data-model-20190328/
manu: this link
([18]https://www.w3.org/TR/verifiable-claims-data-model/) does
not re-direct and
([19]https://www.w3.org/TR/2019/CR-vc-data-model-20190328/) is
broken
... I'll fix it
... ideally we would have re-directs to the vc-data-model
[18] https://www.w3.org/TR/verifiable-claims-data-model/)
[19] https://www.w3.org/TR/2019/CR-vc-data-model-20190328/)
burn: issue #681
... editorial and merged 2 days ago
manu: correct
burn: we can close this
... Ted had a suggested change
manu: I may have missed it
... would you mind raising a PR for that
<manu>
[20]https://github.com/w3c/vc-data-model/commit/d92ceaf801da67c
c698fb80756130c75e04531cb
[20] https://github.com/w3c/vc-data-model/commit/d92ceaf801da67cc698fb80756130c75e04531cb
manu: here's what Dan is talking about
... we should make that change
TallTed: yes, I can make that a PR
burn: that should allow us to close other issues
... the #667 issue the PR has not been merged yet
manu: yes, I did not merge that
burn: would you like to wait until we have a status update from
the director
manu: almost definitely, we will merge it
<TallTed> manu -
[21]https://github.com/w3c/vc-data-model/pull/701
[21] https://github.com/w3c/vc-data-model/pull/701
manu: Ralph is gone, we should get in touch with him ASAP
burn: do you have a plan for closing the three tracking issues?
manu: we should close them but it seems we don't have a WG
resolution for them
<brentz> I fixed the merge conflicts in PR #668
[22]https://github.com/w3c/vc-data-model/pull/668/
[22] https://github.com/w3c/vc-data-model/pull/668/
burn: we were going to defer 632
... what he was asking for was out of scope for our charter
... we have two people on the queue
kaz: I was wondering about the URL for the vc-data-model
burn: can we handle that offline
kaz: sure
<Zakim> ken, you wanted to say implementation guide pr#14 has
four reviews
ken: just wanted to say that there were four reviews for PR#14,
so we can merge
manu: I can merge
burn: can you close the corresponding issue brent?
brentz: sure
burn: can we say that it reflects architectural decisions made
by the WG in regards to #633 and #634
... are there any questions about the proposal?
<manu> PROPOSAL: The Working Group has addressed all concerns
outlined in issues #633 and #634 to the best of their ability,
these are architectural decisions made by the group, and
asserts that the specification reflects the consensus position
of the Working Group and thus the issues should be closed.
Tracking issue #632 is hereby deferred due to the nature of the
request, which is to work on protocol which is specifically out
of scope for the WG Charter.
<TallTed> +1
<manu> +1
<dlongley> +1
<ken> +1
<burn> +1
<brentz> +1
<stonematt> #+1
<DavidC> +1
<bigbluehat> +1
RESOLUTION: The Working Group has addressed all concerns
outlined in issues #633 and #634 to the best of their ability,
these are architectural decisions made by the group, and
asserts that the specification reflects the consensus position
of the Working Group and thus the issues should be closed.
Tracking issue #632 is hereby deferred due to the nature of the
request, which is to work on protocol which is specifically out
of scope for the WG Charter.
burn: not seeing any rejections, so resolved
... I will write that into those issues
manu: for #682 we had a resolution
burn: correct
... #222 is done
... we will be left with 3 non-deferred issues after this call
manu: I'm not getting that
... just confirming that there is nothing the group needs to
make a decision on
burn: there's 688 and 691 which is related to the open issues
... we will try to close out just two of the issues except for
the one referring to the link
... thank you everyone, this is a major step
... talk to you all next week
<kaz> [adjourned]
Summary of Action Items
Summary of Resolutions
1. [23]The Working Group has decided to revert the type
section related to implicit typing to the text of the March
28 2019 Candidate Recommendation, and in addition we add a
sentence which can be wordsmithed later, but the intention
is to say "typing is complex so we refer readers to the
implementation guide which contains more details".
2. [24]The Working Group has addressed all concerns outlined
in issues #633 and #634 to the best of their ability, these
are architectural decisions made by the group, and asserts
that the specification reflects the consensus position of
the Working Group and thus the issues should be closed.
Tracking issue #632 is hereby deferred due to the nature of
the request, which is to work on protocol which is
specifically out of scope for the WG Charter.
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [25]scribe.perl version 1.154 ([26]CVS log)
$Date: 2019/07/17 07:20:24 $
[25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[26] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 17 July 2019 07:22:12 UTC