<rhiaro> scribenick: rhiaro
<stonematt> Zakim who's here
burn: issues and PRs first, then
test suite
... dmitri gave me a test suite update
... will spend the majority of the time on implementation guide
and use cases doc
... This is already in the agenda, I have two items I needt o
add
... one is we need talk about the DID WG creation vote, I
suggest that after the issues
... Another is the UK gov's call for evidence which DavidC will
present. I propose we do that after implementation guide
discussion
... Want to limit the time on that.
... Any suggestions for changes?
DavidC: I've written a draft ?? for mdl and we've got a discussion tomorrow, I sent an early copy to manu and dave to ask them to look at the @context, I didn't circulate it to the group because I thought it was premature, but I will do so after tomorrow's meeting
burn: Going to look at PRs
<manu> https://github.com/w3c/vc-data-model/pulls
burn: manu just submitted a PR
<manu> https://github.com/w3c/vc-data-model/pull/708
manu: it's to address the only
outstanding issue we have, Ted raised issue 704 which was that
people can get mixed up if they copy and paste the
examples
... I found some css magic that makes it so when you highlight
the examples the css that's been added to the PR makes it so
that the comments are not copied
... you can literally select everything, copy and paste it into
somewhere else and thes tuff that's pasted is without the
comments and the ...s
... you can't copy the comments now in the spec
... I also updated some of the accessibility for the comments
and highlighted code, comments are now high contrast blue to
meet accessibility guidelines, highlights are in high contrast
green
... the one thing I did not do ted is point out the fact that the json contains comments,
the only way that someone is going to get those comments in is
either they're using a browser more than a decade old or they
hand type the examples into something
... so I don't know if you still feel like we need to point ou
tthat the json in the examples have comments in there that you
shouldn't copy meaning it would be invalid json
... it's easy to add it, just don't know if we need to
TallTed: browsers are not the only way peopel will interact with this. I turn specs into pdf or print them out. THere are multiple paths here
manu: it's not a big deal, I'll
add the text to the PR
... as soon as I add that text I'll make it a real PR
TallTed: there's no way to preview this before it gets merged because of the way this system works. It sounds good
manu: I have a preview link
<manu> here is the preview link: https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/708.html
TallTed: so now if someone wants to copy the comments there's a new problem
manu: the question is which
problem can we live with
... there's that PR
... that addresses the only outstanding issue, as long as
everyone is happy
oliver: if you scroll down to the jwt section there is a ... in quotes that gets highlighted
manu: I can fix that. Is the ... not supposed to be there?
oliver: it's supposed to be a base64 encoded string
manu: I'll look at that. Anything
else?
... Only example 30 needs to be fix
stonematt: nor Safari
manu: gaaaahhhh css
... I'll fix for all browsers
burn: anything else on this issue?
burn: I believe the only issue we
have left not deferred is the one we were just discussing
... so we're working on 704
... any objections to moving on?
manu: great news is the DID WG
charter is out for formal vote at the w3c. This is public. They
announce charter votes now on a public mailing list, and
request public comment on the charter as well
... What we need to do is clearly communicate with as many W3C
members, specifically AC reps, that we vote in support of the
charter. Right now with 0 notification we have 12 positive
votes. We need 25, and the closer we get to 40 or 50 the better
things will be
... I'm planning on contacting a veyr large subset of W3C AC
members who wanted to be let know when the vote goes out
... It's really imporatn we do that before the end of the
month, that's when we need to get as many votes as we can
in
... if there are companies that we know support the work but
are not yet W3C members and probably never will become them,
they shoudl still send in an email stating that their company
really wants this work to happen
<scribe> scribenick: DavidC
<manu> https://lists.w3.org/Archives/Public/public-new-work/2019Aug/0000.html
Manu asks that we broadly circulate the public announcement for the DID new work item
and asks everyone to ask companies they know to vote in support of it with W3C
All the public comments are very positive. There is just one invisible (probably negative) comment
The vote stops at the end of August
<manu> https://www.w3.org/2019/08/did-wg-charter.html
<manu> https://www.w3.org/2002/09/wbs/33280/did-wg-2019/results
Still determining who the second chair of the WG will be. Dan will be one
<burn> https://github.com/w3c/vc-test-suite/issues
Dan updated the status of the test suite and reports
Andre asked if the implementation reports could link to a repo with the code used for the testing
<burn> DavidC: we have passed all the tests, still need to update the test report
<burn> https://github.com/w3c/vc-imp-guide/issues
<deiu> https://github.com/w3c/vc-imp-guide/pulls
<deiu> https://github.com/w3c/vc-imp-guide/pull/18
<manu> +1 to merge.
Andrei said this PR can be merged
No objections to this
<manu> +1 to merge.
<deiu> https://github.com/w3c/vc-imp-guide/pull/19
<Zakim> manu, you wanted to request we setup github preview...
Oliver asked if we can set up Preview on github
<burn> ACTION: Kaz/chairs to set up PR previews on https://github.com/w3c/vc-imp-guide
Manu thinks the JWT text is broadly ok to merge (with only minor nit picks)
Oliver has to resolve conflicts before the text can be merged
<deiu> Last PR -- https://github.com/w3c/vc-imp-guide/pull/17
<deiu> https://github.com/w3c/vc-imp-guide/issues
DavidC said he will review the schem PR
<deiu> https://github.com/w3c/vc-imp-guide/issues/16
schem -> schema
<deiu> https://github.com/w3c/vc-imp-guide/issues/8
<manu> +1 to defer until Oliver's PR is in
<deiu> https://github.com/w3c/vc-imp-guide/issues/4
manu: Question was how to link to external
resource from a VC
... use a cryptographic hash of some kind. Hashlinks is one (but not only) way
scribenick: burn
DavidC: thought this was about referencing a VC within another VC
... thinks you can just use the VC id
<Zakim> manu, you wanted to say that it's the same problem.
scribenick: DavidC
Manu: VC id on its own is not good enough
because the contents at that link could change
... so need to either base64 encode OR canonicalize, hash and sign
<deiu> https://github.com/w3c/vc-imp-guide/issues/3
<Zakim> jonathan_holt, you wanted to comment the role of multihash
<manu> Multihash and Multibase is what hashlink uses... so, the suggestion includes jonnycrunch's notes.
<dlongley> scribenick: dlongley
DavidC: I agree that anything put on the Web can change ... but we've got a rogue issuer if they are issuing different contents with the same ID.
<oliver> resolved the conflicts
DavidC: I was responding to
Manu's point that you can't just use the ID on the VC on its
own. But my point is that every VC should have a unique ID. If
I include a VC in another VC they should never issue two VCs
with the same ID.
... A VC ID on its own should be good enough on its own.
manu: Strongly disagree. You said
the issuer "should not do X" but there is nothing to guarantee
that they did not do X, either a software bug, MiTM attack,
injection attack, all kinds of ways that might not
happen.
... If you're using a URL to represent the information, you're
using a system that's susceptible to change. You can do that,
but you may also want to be able to update the VC that's
associated with that ID.
... I'm very concerned about us making any kind of suggestion
that including a link to an external piece of data is ok -- I
think we want to at least say that if you want to have
certainty that things haven't changed that you use a content
hash.
... If you don't, the assumption is that that data might
change.
DavidC: When I issue a VC the
link only has to be a URI, there's no guarantee that it even
has to be published on the Web anywhere.
... To reference the VC in the way you're saying, you have to
get a hold of it...
... It's who guards the guards, it's going way over the top. If
I've got something that's digitally signed with a unique ID
inside it that should be enough.
scribenick: manu
dlongley: What we
should say in the impelmentation guide is say there are
different risk profiles.
... If we want to be clear to the person consuming what was signed, you
include a content hash. That way, they can check and see the
content that is signed.
... If you don't include it, you're requring some other mechanism for it to not
change, or you are saying that you find that the data changing
is an acceptable risk.
<manu> to be clear, dlongley and I are saying the same thing.
scribenick: dlongley
DavidC: That is a more balanced approach, certainly.
<brent> +1 as long as its clear that "other mechanisms for ensuring immutability" are acceptable
<dlongley> +1 to brent
DavidC: David introduced the notion of risk in there and we should put that in there, if you trust the issuer and assume it hasn't been hacked, etc.
scribenick: manu
dlongley: This doesn't necessarily have something to do with trusting the issuer... for example, the issuer might lose their domain name... this doesn't have to do with hacking or attacking anyone. We should be clear that links to other pieces of information, even though it is not accessible over HTTP, the information could change. We should be clear to implementers that they include a content hash to make it clear to other people about what content they're signing.
scribenick: dlongley
deiu: May I suggest we leave this issue open and leave arguments in the comments?
<deiu> https://github.com/w3c/vc-imp-guide/issues/4
burn: Ok, then people do need to
enter these comments into issue #4.
... Let's keep this moving offline.
... The group ends at the end of September and in the middle of
Sept. people won't be paying attention because many
participants will be working in the DID WG. Let's get these
issues wrapped up.
<manu> oof, 1-2 weeks will be very difficult :(
<manu> good thing we can update it after the fact.
<deiu> https://github.com/w3c/vc-imp-guide/issues/3
DavidC: I wanted to publish the full details of what we're doing with our implementation... but can't. I had a chat with Dave Longley and the WebAuthn WG put a note in the spec to say that different origins could be used in the future. This is why in our implementation we've had to put a workaround in there.
<Zakim> manu, you wanted to note we demoed this at RWoT7 Canada...
DavidC: So that everyone might implement the same workaround but can't talk about the solution for business reasons.
manu: Just to be clear -- we
cannot talk about IPR in this call, or even suggest anything
that could be under IPR.
... So, don't talk about IPR at all, we don't want to hear
about it on the call.
... The other thing I wanted to mention was a follow up on a
few things off of what Dave Longley had mentioned with David.
This is a feature that we actually demo'd at Rebooting the Web
of Trust.
<burn> Manu is correct. Under no circumstances can you say anything about patents
manu: You can go to your digital
wallet, register your two factor auth device. We demo'd the
Veres Wallet stuff and you register your device and we had to
use a modified version of Chrome, a 10 line change to the
browser to enable this.
... The second rechartering for the WebAuthn WG is working on
this and other groups are requesting this feature too. Because
we registered the FIDO device we were able to create a
VerifiablePresentation and use the device to sign it before
sending it to the verifier.
... We agree it's super important and useful to support. It's
one of the things we may be able to ask for as the DID WG and
this group, to enable this stuff to be enabled through
WebAuthn. Any other alternative we should do a very thorough
review on because it's really hard to get the security
characteristics right.
... +1 for proposing things but absolutely nothing that's IPR
related.
DavidC: Understood.
deiu: Do you think it's worth actually mentioning something from the Veres Wallet in this issue or adding a PR that describes how WebAuthn works?
manu: Yeah, we don't have to be
to be specific about the product, it should work with any
Web-based wallet and it works with the Credential Handler API,
which is also important to note. Also, absolutely no IP around
it, we've established that.
... We want to get something into the implementation guide and
into a WG setting where no one can come in and patent it after
the fact.
deiu: I don't want to put more work on Digital Bazaar's plate but do you think someone can put in a PR for this?
manu: We shouldn't close it, we'll try very hard to get to it but no promises.
deiu: I will remove David
Chadwick from assignees since he can't provide details.
... Do you have anyone specific to assign?
manu: It would be Dave Longley or myself, probably.
deiu: Ok.
<deiu> https://github.com/w3c/vc-imp-guide/pull/19
deiu: I suggest we move forward.
I know Oliver has fixed the conflict in that PR. If you'd like
to quickly take a look at #19.
... We need one more approval.
... Any one against merging PR #19?
<manu> +1 to merge
<DavidC> dlongley: I can take over the minutes now
<oliver> (sorry, i have to leave)
<scribe> scribenick: DavidC
<deiu> https://github.com/w3c/vc-imp-guide/issues/2
<deiu> https://github.com/w3c/vc-imp-guide/issues/1
<Zakim> manu, you wanted to wonder about other sections that are missing.
Manu: are there issues that people would like to see that convert into sections of the document
<burn> https://github.com/w3c/vc-use-cases/
<stonematt> https://github.com/w3c/vc-use-cases/pull/105
Matt: Iot use case being worked on
<manu> +1 to merging IoT use case
Matt: PR#103 needs some tweeking
<TallTed> 35 open issues?
Matt: by next week we need a
clean use case documet
... not looking for new content now.
documet -> document
TallTed is concerned that there are still 35 open issues on the document
Matt responded it is a lot, but he thinks that by reviewing them, a lot will be resolved
Burn: the implementation guide
and use cases are working group notes. They are not
standards
... thus it does not matter how many open issues there are.
<TallTed> Issues *can* be turned into "This is an open question..." in the doc
Burn: all that is required is for
the WG to say it is ready to be published
... that being said, we should of course endeavour to resolve
as many open issues as possible
<burn> +1 Ted
TallTed said that all open issues should at least be addressed by saying we are not addressing this
Matt agreed with TallTed
<manu> https://w3c.github.io/vc-imp-guide/
manu: thinks that aspirational stuff should be
removed
... thinks that LD proofs will use COSE and CBOR more than JWTs
<Zakim> manu, you wanted to ask isn't that the section Dave Longley just wrote?
Jonathan_holt thinks it is hard to specify COSE implementation stuff as it is binary
Manu agrees that this is the way that things seem to be going
scribenick: manu
dlongley: I think we should say: If you're using VCs, use its decentralized extension mechanism... if you're using JWTs, use JWT's centralized extension mechanism.
DavidC: When you pick a URL, should it be dereferenceable? You can use an OID, but you can't look up OIDs... but advantage is, if it's an attribute, and it equals LDAP directory, you can connect the two.
dlongley: perhaps what should happen is you should talk about how you can do that w/ VCs if you want to.
... All this wrt. "what sort of URI should I use?" is an matter of implementation/risk/etc.
DavidC: We can write some of this stuff... matter of cycles and time... when do we want to be done w/ this document.
burn: In a couple of weeks, I'd like to close the document...
<Zakim> manu, you wanted to say how we publish the document.
scribenick: dlongley
manu: When it comes to publishing the document; clearly we won't be able to get all this stuff in based on our track record. The good news is that when W3C publishes an update to an existing document they include a big warning that directs people to the new version. I suggest that when we publish, we immediately put in this document is out of date.
... But then what happens is that the document gets ignored because many of us we'll jump into the DID WG, etc. But noting all these things in the implementation guide is important. That's just a suggestion, when we publish this in the group we point to the live version and direct people over there.
burn: Any other comments or discussion on the implementation guide at this time?
manu: Question for the ZKP folks. The implementation guide doesn't mention it a lot. We may want to point people ... either directly put stuff in the spec or point to external documents, thoughts on that?
brent: I agree, we need more in the guide on ZKPs. I will formally make it my task to make sure that happens.
manu: Awesome, thank you, Brent.
scribenick: DavidC
dlongley: I can scribe again now
<burn> ACTION: Brent to add more text on ZKPs to implementation guide
Manu: we should add more text
about digital wallets
... we need a section about ongoing work so that folks know we
have not finished yet
kaz: is it possible to add
".jsonld" identifier to the "v1" file (and make it "v1.jsonld") on GitHub?
... because github.com site cannot handle mime type
setting
Manu: we cannot change our spec now
kaz: we can continue to use "www.w3.org/2018/credentials/v1" as described by the spec
... my point is just changing the filename of "v1" to "v1.jsonld" (whose content is JSON-LD) on the GitHub side
... maybe the Webmaster knows about nicer setting and I'm asking
him about that, but he is on vacation now and we need to wait for
the response
Manu: can we take this offline please
burn: this has been going on for many months now. we need a call with the W3C web master please
kaz: can have a joint call with the Webmaster after he gets back from vacation
... but as I mentioned, I'm already asking the Webmaster about a nicer solution, so would see the response first
<jonathan_holt> https://github.com/jshttp/mime-db#adding-custom-media-types
<jonathan_holt> https://help.github.com/en/articles/mime-types-on-github-pages
<dlongley> scribenick: dlongley
DavidC: The reason I brought this
to the view of the group -- as you know I've been funded to
look into VC and commercialization and I've been invited to
build an MVP and during that time I've talked to various people
in gov't and the post office about improving their federated
system.
... They've issued a document now asking for views in people in
groups, etc. on why they need to improve the identity system
they use in the UK. Many of which can be answered by VCs.
Rather than me writing my own response it would be much better
if this group would produce an official response from the
VCWG.
... And say how VCs can help achieve what they're looking for.
You'll see if you look at the URL I've provided VCs address the
needs.
<Zakim> manu, you wanted to urge that the group should respond officially... including all entities that are currently members of the WG.
DavidC: We talk about where we can improve trust and questions on each section, lots of good sections we can provide good input. Would you be willing to have the group provide a collective response that we can put our name to?
manu: +1
<Dudley> +1
manu: I feel very strongly that
this group should respond, big stuff, thank you David for
bringing it to the group's attention. Unless there are
objections we should put this out to a group response and
unless there are objections say we support the response as a
group.
... It's kind of every single member saying VCs are important
to use to solve this problem and here's why. And here's a list
of orgs in the group. Would anyone say that they're not
interested in attaching their name to it... in order to do that
we need 1-2 weeks to collect objections, etc. and go through
that process. I don't know if you, Dan or Kaz disagree with
that approach, would like to make that the goal.
kaz: I'm not objecting
personally, but given we've tried to respond, the whole VCWG,
maybe we need to talk with the W3 communications team.
... From a process point.
manu: I think that's a good idea
to involve them. I don't think Comm team has any authority over
WG statements.
... Clearly we want to involve them in that we want to respond
in this way. There's also a liaison that W3C has with ISO... in
this case it's direct, it's David.
... I don't know what we need to do there, we should involve
Comm.
<agropper> I would like to particiapte in drafting a group response.
manu: David, is there a timeframe?
<Identitywoman> +Q
DavidC: It's a public call for
response, anyone can respond. We don't have to be formally
invited. The date is 15th of September (I think) when they want
a reply around about that date.
... Sunday Sept 15th at 11:59 BST.
... They give an email address for response, no more than 2000
words, PDF or word/open document format.
<Zakim> burn, you wanted to ask how we get to a resolution
burn: Thank you. I just wanted to
say that this is a great idea, I do have a practical concern on
how we get to resolution. I have the same understanding as Manu
that the WG can make any statement it wants, doesn't require
approval.
... Manu you're saying that everyone has to put their name to
it, this isn't a document that lists everyone's names, it's
some sort of email response that lists the name of the WG. We
don't need names on it just not objections from the WG to put
the WG name on it.
kaliya: Just a thought to help explain the "why" I figured out -- VCs find low cost infinite technical federation.
burn: Thanks.
kaz: From my viewpoint as W3C
team contact for this WG -- we should talk with Comm team and
then W3 management (if needed) after that.
... So talk to Jeff Jaffe quickly, etc. Talk about this with
them.
... Even if we don't need "approval" here I think talking with
them would be better.
<Zakim> manu, you wanted to note that we took a look at JSON-LD Context for mobile driver's license have feedback.
burn: I agree, it's always good to do that.
manu: Yeah. The other comment is that, David, we did look at the JSON-LD `@context` you sent over, it's in the right direction, needs more work, there are benefits drawbacks to the OID approach. It's really a question about what's best. What's the time frame for us to get a response back to you?
DavidC: The first meeting is
tomorrow, we'll be discussing then. I don't feel strongly
either way what the reference should be and they already use
OIDs in their document. So it seemed to me that we could use
LDAP attribute OIDs and not have our own. The other problem is
that it doesn't publish things.
... We're used to putting things in URLs, they don't publish
things, ISO doesn't share without payment, etc. Trying to
publish things might be against the ISO spirit, whereas OIDs
work, keeps it in house.
<scribe> scribenick: DavidC
Burn: any other topics?
<stonematt> bye all
Since there was no response, burn thanked everyone and reminded them to keep working on the implementation guide
[adjourned]