W3C home > Mailing lists > Public > public-vc-wg@w3.org > April 2019

Minutes for VCWG telecon 23 April 2019

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 24 Apr 2019 02:51:02 +0900
Message-ID: <CAJ8iq9W5V-j=eu11c4e=QRF-=MqTPxS8k1-bMwOaRmyQDFoP9Q@mail.gmail.com>
To: public-vc-wg@w3.org
available at:

also as text below.

Thanks a lot for taking these minutes, Manu and Dave!




      [1] http://www.w3.org/

                               - DRAFT -

                    Verifiable Claims Working Group

23 Apr 2019


      [2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Apr/0022.html


          Adrian_Gropper, Amy_Guy, Brent_Zundel, Dan_Burnett,
          Dave_Longley, David_Chadwick, Kaz_Ashimura, Ken_Ebert,
          Manu_Sporny, Sercan_Kum, Yancy_Ribbens, Justin_Richer,
          Ted_Thibodeau, Joe_Andrieu, Jonathan_Holt, Nick_Carroll,
          Benjamin_Young, Ganesh_Annan, Matt_Stone


          Dan_Burnett, Matt_Stone

          manu, dlongley


     * [3]Topics
         1. [4]Describe plan for the call
         2. [5]VC Impl. Guide
         3. [6]Test Suite Update
         4. [7]Use Cases (https://github.com/w3c/vc-use-cases)
     * [8]Summary of Action Items
     * [9]Summary of Resolutions

   <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> [10]https://github.com/w3c/vc-imp-guide

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

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

     [11] 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
   ... 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

   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

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

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


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


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


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

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

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

     [16] 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> [17]Issue 9

     [17] https://github.com/w3c/vc-imp-guide/issues/9

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

   <inserted> [18]Issue 8

     [18] https://github.com/w3c/vc-imp-guide/issues/8

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

   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

   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> [19]Issue 6

     [19] https://github.com/w3c/vc-imp-guide/issues/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> [20]vc minutes during tpac 2018

     [20] https://www.w3.org/2018/10/25-26-vcwg-minutes.html

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

     [21] https://github.com/w3c/vc-imp-guide/issues/5


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


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

   <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.
   ... [24]https://github.com/w3c/vc-imp-guide/issues/4 -- who
   wants to address this one? Keep it moving forward.

     [24] https://github.com/w3c/vc-imp-guide/issues/4

   dlongley: I'll take this one.

   burn: Issue 3 -

     [25] 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 -
   ... Wonder if dmitri would be willing to take this one.

     [26] https://github.com/w3c/vc-imp-guide/issues/2

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

   burn: Issue 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

     [27] https://github.com/w3c/vc-imp-guide/issues/1

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

   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> [28]Test suite issue 9

     [28] https://github.com/w3c/vc-test-suite/issues/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

   <dlongley> [29]https://annevankesteren.nl/2012/12/cors-101 as

     [29] https://annevankesteren.nl/2012/12/cors-101

   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

   burn: Thanks everyone, we have to move on.

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

     [30] 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> [31]https://github.com/w3c/vc-use-cases

     [31] 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> [32]https://w3c.github.io/vc-use-cases/

     [32] 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.


     [33] 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....


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

     [35] 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
   ... 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

   <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

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

   <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

   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> [36]https://github.com/w3c/vc-use-cases/issues

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


     [37] https://github.com/w3c/vc-use-cases/issues?q=is:issue+is:open+sort:updated-asc


     [38] 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> [39]https://github.com/w3c/vc-use-cases/issues/33

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

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

     [40] 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> [41]https://github.com/w3c/vc-use-cases/issues/18

     [41] https://github.com/w3c/vc-use-cases/issues/18


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


     [42] 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> [43]https://github.com/w3c/vc-use-cases/issues/49

     [43] https://github.com/w3c/vc-use-cases/issues/49

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

   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

   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

   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

   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.

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes manually created (not a transcript), formatted by
    David Booth's [44]scribe.perl version 1.154 ([45]CVS log)
    $Date: 2019/04/23 17:49:06 $

     [44] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [45] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 23 April 2019 17:52:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 23 April 2019 17:52:11 UTC