<scribe> scribenick: oliver
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
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> 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
no objections
<manu> 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
<manu> 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> 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> 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> https://github.com/w3c/vc-data-model/issues/526
burn: this is complete
<manu> https://www.w3.org/TR/verifiable-claims-data-model/
<manu> https://www.w3.org/TR/2019/CR-vc-data-model-20190328/
manu: this link (https://www.w3.org/TR/verifiable-claims-data-model/)
does not re-direct and (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
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> 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 - 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 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]