- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 24 Apr 2019 02:51:02 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2019/04/23-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Manu and Dave!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims Working Group
23 Apr 2019
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-vc-wg/2019Apr/0022.html
Attendees
Present
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
Regrets
Chair
Dan_Burnett, Matt_Stone
Scribe
manu, dlongley
Contents
* [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
guide.
<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
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
[12]https://github.com/w3c/vc-imp-guide
[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
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...
[13]https://w3c.github.io/vc-imp-guide/
[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-expressi
on
[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
[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
on.
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
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> [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
[22] https://w3c.github.io/vc-imp-guide/#hashlinks
[23]https://w3c.github.io/vc-data-model/#content-integrity-prot
ection
[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
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.
... [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
[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 -
[26]https://github.com/w3c/vc-imp-guide/issues/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
in.
burn: Issue 1 --
[27]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.
[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
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> [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
"application/octet-stream"
<dlongley> [29]https://annevankesteren.nl/2012/12/cors-101 as
well
[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
well.
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
[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....
<JoeAndrieu>
[34]https://w3c.github.io/vc-data-model/#use-cases-and-requirem
ents
[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/1FAIpQLSflUopxcqMlIoZskjq
Ars5IqorvF9vXXSRMLGQSJ0hoaGYurA/viewform
[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
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> [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
<JoeAndrieu>
[37]https://github.com/w3c/vc-use-cases/issues?q=is%3Aissue+is%
3Aopen+sort%3Aupdated-asc
[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
[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
this.
<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>
/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.
[42]https://github.com/w3c/vc-use-cases/issues/48
[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
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.
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