<scribe> scribe: manu

Describe plan for the call

burn: This is our new time for the call - we're not going to be doing what we have been doing -- not going to look at issues.
... The plan today is to look at implementation guide, need to produce that - also, need update on test suite that can give us an update.
... We also need to talk about Use Cases document, will have time at end for registries discussion
... Anything else we should discuss in today's agenda?

VC Impl. Guide

<burn> https://github.com/w3c/vc-imp-guide

burn: The plan is... there are issues that we need to address from the VC ... requirements... look at issues list, there are already issues there for those.
... That we promise in our implementation guide - already have issues for a number of items that need to be added -- what we need is, give people an opportunity to - if they want additional points that must be raised, that this is an opportunity to bring them up... whether that's appropriate. For now, for this guide. Reminder that we plan to publish as a W3C Note - it doesn't have to satisfy the consensus requirement.
... It doesn't require external review, we're ok with that document existing.
... The important thing though, is to cover requirements from specification. My first starting question is - anything anyone is aware of that is listed as an issue that must be in this guide.

<burn> https://github.com/w3c/vc-imp-guide

DavidC: Your question, as I understood it was, is there anything that MUST be in the implementers guide. Some of this depends on how the issues are resolved, what's added to current data model document... if subsequent PRs put it in Data Model document, they don't need to go in implementation guide.

burn: Fair enough, this isn't the "announce it or lose the opportunity"... just any discussion that's needed.
... If you'd like to submit an issue against implementation guide, with respect to what you're thinking about, if this gets resolved in main document fine, if not, put it in implementation guide.

DavidC: There are a few things that need to be in @context... why does it need to be in a certain order.
... If we are mandating that implementers must support @context... do we have to mandate they do all short form aliases?
... What is the issue between supporting or using IRIs, or short form aliases.

burn: I'm going to wait for people to join queue, provide input.

dlongley: Looking at some of these questions, do we mandate that everyone uses short form aliases... no, we don't want to do that. If you want your VCs to be easily processible by JSON-only processors, you should make sure you do a few things... make your @context available via URL, make sure you use short form because that's probably what people will use, we don't need to mandate this, just guidance.

<burn> For late joiners, we are looking at https://github.com/w3c/vc-imp-guide

dlongley: The order of things in the @context... the @context field when processed by a JSON-LD processor, when it goes through each element in an array, any definitions, redefinitions, we are recommending everyone use @protected feature in JSON-LD 1.1. I haven't thought through the consequences that it would be ok to change order up... would be good to say
... this is the order that you should have

<Zakim> burn, you wanted to ask either dlongley or DavidC to add issue for this

burn: Can either of you add issues for these as appropriate. Anything in VC spec as clarifications would be good to specify in some way, track in implementation guide or in VC spec.

<DavidC> I will add these issue to the guide

dlongley: Most of these things are implementation guide things...

burn: Ok, looks like David is going to add these things to the guide.
... We are looking at issues, seeing if other issues you may have...

https://w3c.github.io/vc-imp-guide/

burn: Link to guide is wrong...

<Zakim> manu, you wanted to say we need to remove COSE stuff

https://w3c.github.io/vc-imp-guide/#cose-signature-expression

<dlongley> manu: Just a quick note, there's stuff in the spec right now, in the document right now that talks about COSE signature expressions and we probably need to remove some of that. We were hoping to make more progress on that during the WG than we did, so there are two parts to remove there.

<dlongley> manu: I think those are the only things we need to remove. The other question is, this was going to be published as a NOTE and then handed over to the CCG to continue to edit and modify so that it's an up-to-date doc (Evergreen).

<dlongley> manu: Rather than getting old.

burn: We do want to continue it - we do still have to publish as a NOTE, but then hand over essentially.
... Anyone else have any other comments on implementation guide? Either the contents, the issues in the repo?

DavidC: Does the whole issue of extensibility, that we have only defined core extension types, we haven't specified any of the actual content... should we provide some guidance on how to extend? How to best do it to create an international community? So when someone defines an extension in the EU, someone doesn't do that in US? What's the procedure for extensions? Chatroom?

<Zakim> manu, you wanted to note Section 4

https://w3c.github.io/vc-imp-guide/#extensions

<inserted> DavidC: What about how you write extensions? What about that? Where do you go? How do you coordinate?

<dlongley> manu: We have a section in the implementation guide where we talk about extensions and I think you're right we should mention a couple of things: 1. How do you define a new extension, credential type or other extension at an extension point, 2. How do you register it once you're done, and that has to do with the CCG extension registry ... you should have a spec and a test suite, that kind of stuff.

<dlongley> manu: We should put that in there, I agree. That's section 4, how do you define an extension, what are the files you have to create, and where should you register it. The proper venue is the CCG at W3C to have those more detailed conversations. Then there are bigger things like schema.org like things for credentials as well. There could be a site for all the different kinds of VCs, the types, but not the extension points. Driver's licenses, age

<dlongley> certificates, proof that you went to a certain class, etc.

<dlongley> manu: We can also point to the Credential Engine and the registry that the educational vertical is already working on.

burn: I'd like to look at specific issues, would like to make progress on VC issues.

<burn> https://github.com/w3c/vc-imp-guide/issues

burn: I'd like to go through the issues in the implementation guide - see if we can assign people to process issues.

DavidC: Either Dave or I could work on it.

burn: I'll assign both of you.

<inserted> Issue 9

burn: Issue 9 - @context value ordering, probably same thing.

<inserted> Issue 8

burn: Issue 8 - add sections outlining benefits/drawbacks...
... we discussed this at F2F... manu has written section on LD Proofs...

manu: I wrote the LD Proofs part, waiting on Oliver to write the JWT stuff.

ken: Should we put something in about ZKPs? I think it would be beneficial.

manu: +1 to write something about ZKPs.

burn: I'm not sure how much we'd need to have...

ken: A paragraph or two?

burn: Yes, that sounds good.
... I'm adding that to the description on the issue itself...
... Ken and Oliver are assigned to that one.

<inserted> Issue 6

burn: Issue 6... progressive trust or graceful degradation... who wants to take that one?

brent: I'll take that one.

DavidC: This is a request for clarification about this issue - may understand progressive trust... trusted negotiation... build up to level of high trust? Is that same thing that's meant by this issue here?

burn: Would you mind doing that, DavidC?

DavidC: Ok, yes, I will look into it.

<kaz> vc minutes during tpac 2018

burn: Any other comments on this one?
... Issue 5 -- https://github.com/w3c/vc-imp-guide/issues/5

https://w3c.github.io/vc-imp-guide/#hashlinks

https://w3c.github.io/vc-data-model/#content-integrity-protection

<dlongley> manu: We have a section in the spec that talks about hashlinks and linking to images, and content integrity, in section 8.2 in the VC data model spec.

<dlongley> burn: So this might already have been addressed in the VC data model spec.

burn: Do we need to say anything more in the implementation guide?

<dlongley> manu: This is Bohdan's thing, he wanted some way to link to external content, he introduces a hash and a location, all that kind of stuff. The chats I had with him, he seemed to be happy with the hashlinks approach and just reusing it. We would have to check with Bohdan. If he's not happy with it, then we can always add it to the implementation guide later in the CCG.

<dlongley> burn: Correct. We just need to do the cross check and make sure he's ok with it.

kaz: Ok, so we can check with Bohdan

burn: The original issue closed some time ago... just asking if it's ok to close implementation guide issue.

kaz: just wondering if it's ok to mention his name within the minutes. is that fine?

burn: Yes, he's the original submitter, that's fine.
... https://github.com/w3c/vc-imp-guide/issues/4 -- who wants to address this one? Keep it moving forward.

dlongley: I'll take this one.

burn: Issue 3 - https://github.com/w3c/vc-imp-guide/issues/3

dlongley: I recommend that we ... we may make a statement... you can put my name down. I don't even know if we need anything here... I don't think we can move forward w/ WebAuthn in it's present state... but once they make that change, then we can write something up when this document is back in the CCG.

DavidC: We have some students looking at this very issue now -- if you have experience to say how this might not work, that would be helpful to us.

dlongley: Yes, would you like me to write something up in the implementation guide? Or just let you know now?

DavidC: Time is of the essence.

dlongley: ok, I'll send what I have.

burn: Issue 2 - https://github.com/w3c/vc-imp-guide/issues/2
... Wonder if dmitri would be willing to take this one.

DavidC: I'm happy to take this one. It's a topic I'm interested in.

burn: Issue 1 -- https://github.com/w3c/vc-imp-guide/issues/1
... Consensus at the Barcelona f2f meeting on Mar 4 2019 was to add a JSON schema for the VC data model, to help implementors.
... We need someone that is willing to add JSON Schema here.
... Waiting for volunteers to write that JSON Schema.
... We are not going to be able to get past doing... it'll be expected from the outside.
... I'll move on for now, it needs to be addressed.
... Ok, we've gone through all issues for VC Implementation Guide.

<inserted> manu: We should check in with Andrei, who volunteered to write this document

<inserted> manu: We may also want to list implementations

Test Suite Update

burn: Any updates on the test suite?

<Zakim> manu, you wanted to ask about implementations.

<dlongley> manu: I know that Dmitri had an action item to work on the vc-js implementation.

<dlongley> manu: And making sure that the normative statements were good and were testable.

<dlongley> manu: The question I have is -- who is currently working on an implementation? You're working on an implementation and running it against the test suite.

DavidC: We are working on an implementation and will use test suite... Two questions about implementation spreadsheet... Took the liberty to add a column on "nonTransferrable"
... The other thing I raised as an issue, got buried, I raised the issue of the refresh in the VC... I know we cannot change the spec at the moment w/o going to another CR, the VC is allowed to have the refresh in it... but what I'd like to suggest... implementation table, if people can provide implementation for VCs but not VPs for refresh service...
... Then we can remove it...

yancy: I've been working on implementing, I have raised a few issues, they are being addressed, but happy to go over those.

SercanK: I know that a colleague of mine is currently working on an implementation... need to double check... just letting you know, will follow up with them and come back.

ken: I'm working on one, and we have an independent 3rd party also working on one... focused on ZKP tests.

<Zakim> burn, you wanted to remind people that initial implementation reports need to be submitted over the next few weeks and to ask if any replies to DavidC

burn: Initial implementation reports need to be submitted over the next couple of weeks... any modifications, we need those now.
... If anyone has responses to David's comment, refresh service... refresh issue...

<jonathan_holt> yes

yancy: Coming close to being complete... seen one as outstanding... content type is incorrect... don't believe that's one that's been addressed yet.
... That's issue 9 on issue tracker.

scribenick: dlongley

manu: You're talking about the content type for the v1 context?

yancy: Specifically, that fails on the JSON-LD playground.

manu: Yes, the W3C team needs to fix that and we've notified them of that and this was the reason that we had a concern about putting this at W3C because those changes take a while to get through the system.

<DavidC> Do we have a template for implementation reports. For those of us who have never written them before, what is needed?

manu: Kaz, the JSON-LD context needs to be served with an application/ld+json mime type and the proper CORS headers need to be set.
... Do we know when that will work?

kaz: Maybe an additional .htaccess setting required on the W3C site.

manu: It's CORS too, if you run a VC processor in a browser you won't be able to fetch that context, there are additional CORS headers that need to be set.

kaz: Sorry, I didn't look into this in detail. I will talk to the systems team again.

manu: Are we tracking this in an issue? Yancy, you said #9 is that issue?

<inserted> Test suite issue 9

yancy: Yes, in the test suite.

manu: Yes, this isn't just that it's the wrong content type, it's also that the CORS headers aren't set.
... Let me modify this.
... Wrong content type *and* CORS headers not set.

<rhiaro> "Access-Control-Allow-Origin: *" ?

<jonathan_holt> content-type is currently set to "application/octet-stream"

<dlongley> https://annevankesteren.nl/2012/12/cors-101 as well

scribenick: manu

burn: Anything else on this general topic, test suite?

scribenick: dlongley

manu: Yancy said he has a couple of issues raised, I think we are making progress in the issues, and I don't know if it would be easier to resolve them in a high bandwidth setting here on the call.
... Is there anything that is blocking you from making progress on your implementation?

yancy: Not besides what's on the issue tracker. I can implement caching. If we can just inline the context so we don't have to worry about CORS and these different types of issues that have been holding me up.
... I can continue around the caching, but it would be nice to address the other PR that was on going.

manu: I think one of the confusions in that issue was about inlining the context. Amy thought one thing and I thought you meant using a hashtable. And Amy thought you meant using the URL. Which did you mean?

<rhiaro> I took to mean putting the JSON object of the context in there

yancy: I was under the impression it may be possible to shove the entire JSON object in the context so it wouldn't have to resolve to any external URL.

manu: It is possible to do that, but that would then require JSON processors to do a deep-dive into that object and look for every key-value pair in there and it would raise the burden on JSON-based processors quite a bit. They would effectively have to do deeper JSON-LD processing which people have said they don't want to do.

<rhiaro> manu, not if we fix the exact string of the json object to be included?

<rhiaro> but maybe that's a hack..

manu: The approach we're trying to go with here is that if you hard code a set of URLs then you can just check for those and you can just do JSON based processing you don't have to do any JSON-LD processing on that. You raise the burden on pure JSON implementations to the point that people wouldn't be happy if you made them check more than just a URL.
... Does that make sense?

yancy: Yes, that makes complete sense.
... I didn't think that it would increase the burden that much to do a string compare of a JSON object instead of a URL... I hadn't realized that was an issue and that it could be a possible reason for concern.

manu: Based on what the spec currently says... are you doing a JSON based processor a JSON-LD processor?

yancy: I'm trying to do a JSON-LD processor, but because we have to go to an external resource I've been having issues with retrieving the context. I could hard code or cache it into my implementation, either of those two would help me move forward with my implementation.

manu: I know we should stop this conversation soon, Dan. I believe that's a good way forward. Current JSON-LD implementations have a hard cache where you can ship a context with your implementation and you can use `documentLoader` to load docs directly from your implementation.

yancy: Ok, no problem. If we could formalize what the actual context is in the spec that would go a long way to helping as well.

burn: Thanks everyone, we have to move on.

Use Cases (https://github.com/w3c/vc-use-cases)

scribenick: manu

burn: Thanks to the implementers, we need to spend a little more time doign that - we'll put aside some time to do that in the future... please do not hesitate to email the list w/ questions as well.

<JoeAndrieu> https://github.com/w3c/vc-use-cases

JoeAndrieu: The main thing I want to get out of this call is for folks to step up and review our domains...

<JoeAndrieu> https://w3c.github.io/vc-use-cases/

JoeAndrieu: We have a handful of things we're trying to wrap up - we have focal use cases, we have a third one... PADI diving instructor use case... other thing we want to do - update user needs document, which starts w/ diagram.

https://github.com/w3c/vc-use-cases

JoeAndrieu: We need to find which of these meet which requirements - that they have representational use cases... in the data model, we have some requirements from use cases....

<JoeAndrieu> https://w3c.github.io/vc-data-model/#use-cases-and-requirements

JoeAndrieu: In this section, we have a list of requirements that we've distilled from the use cases, we just updated this a few months ago. We need to get this list of requirements evaluated against that set of domains... finance, education, healthcare, IoT...
... What we've put together is a Google Doc... use cases in a domain, against those requirements... we have a google form.

<gannan> here is the google form https://docs.google.com/forms/d/e/1FAIpQLSflUopxcqMlIoZskjqArs5IqorvF9vXXSRMLGQSJ0hoaGYurA/viewform

JoeAndrieu: One of the things I was hoping was to get volunteers for domains... we need to get through this in parallel.
... It's an easy form, you select your domain... then you put in your content... select a domain, click thorugh - for that domain, you put check mark beside each requirement explicitly mentioned.

<ken> How many reviewers are needed for each category?

JoeAndrieu: This will give us coverage wrt. what we have in data model.
... It would be good to get 2-3 per domain. For focal use cases, we found that sometimes it would be ambiguous, so higher coverage would be good.
... It would be great to have folks step up and say yes please... instructions - might give group some time to work on it... 27 items, 5-10 minutes to do a domain.

<ken> I can review IoT, healthcare, finance

<jonathan_holt> I can do healthcare, I might add a use case for Immunizations

<SercanK> I will help with the Legal Identity and Professional credentials

<SercanK> *can

<ken> I suggest Ned Smith to review IoT

jonathan_holt: The only thing missing is hierarchy of trust... in any of these use cases, you have a VC, forward entity is a subject... person signing credential, that person... following their chain of trust up, they have authority, their credentials to make that claim.
... For example, licensing for physicians, licensed in a particular state, you don't share one key for signing, you have to show that key is a member of an organization.

<burn> No, web of trust, not hierarchy. Each verifier needs to decide which issuer they trust. Why is up to them.

JoeAndrieu: Controller of key is a member of organization... the difficult thing is fitting all of that into a paragraph... we do a deeper dive into focal use cases... we say who is dependent on which parties to do it correctly.

<SercanK> with Becker-Carroll

SercanK: We do a lot of government work, legal identity... professional credentials, those are two that we're very interested in... would like to help in any way that I can... I fill in Google Form, fill in ones I think are mentioned in the paragraph?

JoeAndrieu: If you imagine how it could be realized, and think "of course they're going to do X", then check "X". Thanks for the offer to help out.
... We will send out emails to get people involved...
... What else do we want to cover in our window here?

<JoeAndrieu> https://github.com/w3c/vc-use-cases/issues

stonematt: Does everyone have clarity on how the Google Form works? I think yes. We need help on issues, bunch of open issues on Github repo... comment as appropriate, need to start processing them, what are must haves, defer, close....
... We could take a look at some of those issues... there are some editorial ones, typos that we can ignore... but others that are interesting.

JoeAndrieu: Ok, let's triage issues...

<TallTed> also need to fix diagram terminology... e.g., Verifier not Inspector

<JoeAndrieu> https://github.com/w3c/vc-use-cases/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc

https://github.com/w3c/vc-use-cases/issues/35

Establish criteria for use cases, provide outlet for examples

JoeAndrieu: We are updating the needs map here... potentially including new use cases, after we get that engagement.

<stonematt> https://github.com/w3c/vc-use-cases/issues/33

<inserted> JoeAndrieu: Closing this one...

JoeAndrieu: This was a noble idea, but we're not going to do this.

<stonematt> https://github.com/w3c/vc-use-cases/issues/40

JoeAndrieu: This was initially your question --

stonematt: This is how the data model works... what are the requirements on the issue to support holder to do these things.

<dlongley> manu: It sounds to me like -- this one is basically, the issuer has to compose the credential in a way that makes it decomposable and that's the high-level thing/way to do it. At the low level ZKPs can enable you to do this. You can show that the issuer is constructing the credential in a specific way so the holder can show a subset of it (or using ZKPs).

JoeAndrieu: Matt, do you want to close this? Is that question answered? Are there open questions?

stonematt: Maybe we can take in education use case and feather in ZKP/selective disclosure use case... requirements bullets in data model.

ken: Is the ZKP sufficient? Have to show how to do selective disclosure using other types of mechanisms?

JoeAndrieu: From a use case perspective, we need to explain where ZKPs would be important.

ken: Ok, that's sufficient.

<stonematt> https://github.com/w3c/vc-use-cases/issues/18

<stonematt> /github.com/w3c/vc-use-cases/issues/48///github.com/w3c/vc-use-cases/issues/48

stonematt: Going to close this one, we aren't going to reopen this terminology discussion.

https://github.com/w3c/vc-use-cases/issues/48

JoeAndrieu: If you look at retail, it looks pretty light.

<Zakim> manu, you wanted to volunteer Nick :)

<stonematt> https://github.com/w3c/vc-use-cases/issues/49

manu: perhaps Nick from Koupon Media could provide a retail use caes?

Nick: Happy to take a shot at it.

stonematt: 49 feels like a wallet use case...

JoeAndrieu: The impact on out of scope is, in use cases document, we have user tasks, issue, assert, verify, store, retrieve, revoke... those are what we break down wrt. what a user can do w/ a VC.
... We also have retrieve and move in the diagram, thing around storage... we also have amend, that feels weird there.

stonematt: We are talking about use cases, more expansive beyond data model, implies other things... simply a description/definition?

JoeAndrieu: There is a description for each one, looking at this now, this storage stuff is fine, we do talk about portability of claims... holder is in control of them, they can store them wherever they want... could withdraw title of issue.
... storage, retrieve, move is fine.
... amend claim is strange...

<TallTed> amend is basically revoke + issue

<DavidC> Amend could mean update to the latest PII about the subject

JoeAndrieu: I guess refresh service is about that... may bind refresh to holder not issuer.

<Zakim> manu, you wanted to talk to amend.

JoeAndrieu: Revoke doesn't amend content... if there are changes in VCs w/o holder going through authentication ceremony, recipient doesn't know if it's changed, can know it's revoked, not changed.

<dlongley> manu: I was going to make a meta argument. This is a graph based and so to amend things you just make statements about the old credential.

<dlongley> manu: It's natural to just reissue a bunch of credentials, if you have credential #1 you can start adding and subtractive is more difficult, it will probably fall into what Ted is talking about where you'd revoke and then issue a new credential. There are multiple ways to amend, to add to the graph, to the data model itself.

TallTed: There is sort of a question of whether these things are being verified... the fact that it's verifiable, doesn't mean it's verified.
... It seems to me that an amendment requires that you re-issue a credential in some manner, there's minimal extra burden in revocation + issue of new data.

stonematt: You're almost describing a "replace" action.

<brent> +1 to replacing over amending

<ken> agree with Ted

TallTed: The idea of attaching amendments to a VC that quickly becomes, to me, unwieldy... plus, add, change, plus, add, change... that could get ugly quickly

<stonematt> +1 to replace concept over amend

JoeAndrieu: The notion of amend makes me think that distributed VCs are going to be amended.... user tasks say amending, but prose does not.

stonematt: If it's only in use cases document, we have opportunity to remove that word... this is more of a data model / user agent thing.
... so, it might be a simple touch to use cases document, have CCG figure out details later.

JoeAndrieu: What do we want to do w/ this issue, then?

stonematt: Sounds like we talk about storage already, then take out amend language.

JoeAndrieu: That sounds reasonable...
... We'll have to talk about this a bit more - we'll have to update...

stonematt: 5 minute warning before end of call...

JoeAndrieu: I think we can wrap, we'll have to keep pushing through issues... use case team can go through issues... sticky open items... future open call.

DavidC: I wanted to go back to earlier issue, about PING - graceful degradation - applications failing gracefully...

burn: ok, thank you David... not a use case issue, from the first hour of the call.

JoeAndrieu: Can we have some volunteers? DavidC - would love to have you take a look... brent is around as well ... let us know if we have good coverage.

<DavidC> OK

JoeAndrieu: We'll reach out to folks to get more involved.

burn: Anything else before we wrap the call today?

<stonematt> bye all

<SercanK> thanks

burn: Ok, thanks very much everyone - we are doing this (=2-hour call) until further notice... talk again next week. We'll go back to VC issue processing.