<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> 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> 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> 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]