- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 1 Aug 2018 01:33:48 +0900
- To: public-vc-wg@w3.org
available at:
https://www.w3.org/2018/07/31-vcwg-minutes.html
also as text below.
Thanks a lot for taking these minutes, Gregg!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Verifiable Claims WG Telecon
31 Jul 2018
Attendees
Present
Chris_Webber, Matt_Stone, Ganesh_Annan, David_Chadwick,
Gregg_Kellogg, Alex_Ortiz, Dave_Longley, Gregory_Natran,
Kaz_Ashimura, Clare_Nelson, Ted_Thibodeau, Joe_Andrieu,
Manu_Sporny, Yancy_Ribbens, Kaliya_Young(invited_guest)
Regrets
Dan_Burnett
Chair
Matt_Stone
Scribe
gkellogg
Contents
* [2]Topics
1. [3]Introductions
2. [4]Action Items
3. [5]Assign owners to unassigned issues
4. [6]External review of data model spec
5. [7]To Delegate or not to Delegate
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<scribe> scribenick: gkellogg
<stonematt>
[10]https://lists.w3.org/Archives/Public/public-vc-wg/2018Jul/0
015.html
[10] https://lists.w3.org/Archives/Public/public-vc-wg/2018Jul/0015.html
Introductions
kaz: I’m Kaz Ashimura from W3C, I’m going to be the team
contact from tomorrow. I’ve been working with Dan Burnett for
voice and multimodal working groups for 10 years. Recently,
I’ve been working on WoT and Web TV things. Now with all of you
on Verifiable Claims :)
<manu> Welcome to the group, Ashimura-san!
<stonematt> welcome Kaz!
<kaz> thank YOU!!!
<dlongley> Welcome!
Action Items
<stonematt>
[11]https://docs.google.com/spreadsheets/d/1XIRn3VltrK_Dxqz0VyD
xPi265sW47EMSKVKUXmMkI70/edit#gid=0
[11] https://docs.google.com/spreadsheets/d/1XIRn3VltrK_Dxqz0VyDxPi265sW47EMSKVKUXmMkI70/edit#gid=0
stone: Several of these action items have been completed.
... We’ve had a running discussion on changing terms, which is
ongoing.
yancy: I’ve been reviewing the PR on the BTCR example, and am
about ready to submit. When I looked up the DID on testnetbed??
it doesn’t seem to be locked; maybe it’s a lack of my
understanding of how the VC is tied into the DID.
manu: Not an expert on BTCR, but happy to help.
... Which field is the data in?
yancy: in the DID schema, there’s a “claims” key and the DID
that the VC is tied to, the array is empty.
manu: The test suite doesn’t look up DIDs, just does syntactic
validation. it doesn’ tmatter that it can’t be looked up. The
empty claims is a problem.
yancy: I’ll update the PR with an example.
stone: I think this is issue #32, so I’ll close it out of the
sheet and track on github.
Assign owners to unassigned issues
<stonematt>
[12]https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Ai
ssue+is%3Aopen+no%3Aassignee
[12] https://github.com/w3c/vc-data-model/issues?utf8=
<dlongley> [13]https://github.com/w3c/vc-data-model/issues/209
[13] https://github.com/w3c/vc-data-model/issues/209
stone: I’ll take responsibiity for #209 pseudo-anonymity
... We have use cases for anonymity. I may be in control of a
credential, but you don’t necessarily know who I am.
joeandrieu: If the issuer want’s to make a correlatable VC,
they can. If you want anti-correlaction, it comes out of the
data model, so it seems obvious that it could be done.
<dlongley> +1 to Joe
<stonematt> +1 thank you JoeAndrieu
stone: probably not much more that needs to be added.
External review of data model spec
stone: The most recent note is from tzviya for accessability.
Dan and I will continue to track.
... An issue opened on the namespace URL. There’s an “external
review” tag we can use to track such issues.
manu: I’ll take care of it.
To Delegate or not to Delegate
<stonematt> [14]https://github.com/w3c/vc-data-model/issues/204
[14] https://github.com/w3c/vc-data-model/issues/204
stone: It’s been an ongoing discussion about the role of VC and
their use towards authorization and what access or privilages
they might grant.
... We’ve had a robust discussion, so the item today is to
decide how we treat it in version one of the spec, knowing that
it may have implications.
cwebber: To recap, there have been 2 ways we’ve talked about
delegation, so I suggest two terms, that for authorization and
one for distribution, about if you should pass on to someone
else.
... For authoriazation, my understanding is that the source of
disagrement is that authorization should not be about the VC
spec. It should be about parties making statements.
... The decision to build an authoriazation system on top of VC
has been explored, and there’s an understanding that it my be
access control or role-based, and DavidC has noted that we
can’t stop someone for doing this, but I don’t think we should
bake it into VC itself.
... This could be done as an extension, and I’ve offered to
review.
... By not having it in the spec, we’ll keep it focused, and
we’ll be able to leave the decision on how to do it as a
separate decision.
DavidC: This came in because I put in a PR on holder !=
subject, and I wanted to cover these cases. Chris mentioned
that we need to allow credentials to be passed on, and one way
is if Ii were assigned a role, and I wanted to give it to
someone else, I would pass on; called “delegation”.
... I’m happy to give a different name, but we need delegation,
and we need to tell the verifier about this so they know the
holder is authorized to do so.
... I believe cwebbrer things anyone can hold a VC, but I have
a somewhat different feeling, that the verifier needs to know
the holder is authorized to use it.
kaz: Procedural comment, for today’s meeting Kaliya is an
invited observer. Is that OK?
stone: generally speaking, these calls are public. We need to
be careful about comments people make, but the calls are open.
manu: No, calls aren’t open, they’re membrer only.
kaz: If Matt as the Chair is OK and the invited guest is aware
of the W3C patent policy, no problem.
... but we need to make sure that
... for today’s call, she’s accepted as an invited observer.
<identitywoman> yes I am aware of the policies.
<identitywoman> (it is very unlikely I will say much)
manu: To be clear, these are member-only calls covered by the
patent policy. identitywoman is joining through Spec-Ops, and
hasn’t yet agreed to the patent policy, so please don’t make
comments about these things (which she has).
<Zakim> manu, you wanted to suggest that we actively discourage
ACL/RBAC on top of VCs and that being the position of the
group... pointing to OCAP as a good future direction that the
manu: We’re talking about delegation and authorization, and I
agree with cwebber that we should keep authorization out; we’re
working on it in the CG. I think DavidC is right that people
will build these things on top of VC; some think it’s a bad
idea (I do). In the past, it’s led to bad practices.
... We should have something in the spec warning about this.
Specifically access control lists are a bad practice and we
should stop doing that.
... From a charter perspective, authorization is out of scope.
DavidC said that verifiers need to know, but that’s a protocol
issue.
... We have a practice that requires the holder to countersign.
The issuer will have issued it to a subject, and the signture
will be associated with that subject.
manu: I don’t think any changes are needed. We also have terms
of use, that can allow such use. That may or may not meet the
bar for authorization.
... It’s a big problem to solve, and we’re too late in the WG
life cycle to tackle
<Zakim> cwebber, you wanted to describe who can be a holder (vs
who is authorized to be a holder)
cwebber: I think manu covered it. The two things that were
discussed illustrates why we need two different terms,
delegation vs authorization.
... DavidC brought up some things about distribution, but manu
discussed this.
DavidC: I introduced this topic because of subject != holder,
manu said we know this because of the proof, but in this case …
... We need something in the model to know S!=H, and we need
that in the datamodel, terms of use is not sufficient.
... If we can find solutions without delegation, then I’m
happy, but let’s remove S=H from the discussion, it’s about
S!=H.
dlongley: I don’t think there’s something simple to add to the
data model to handle this. It’s significant scope creep, and
we’ll end up having to solve a larger problem we weren’t
chartered for. The data model allows for extensions to solve
such things.
<TallTed> +1 secondary credential creation
dlongley: A subject that wants to delegate can issue another
credential; if the verifier understands this, they can use that
information.
... There’s a signficant amout of work to do to allow this to
be done properly.
JoeAndrieu: The semantics of VCs are about who said what; they
crypto assurances don’t extend to discuss such policies. We
don’t have crypto for S!=H.
... It’s worth discussion the limits of the math in the spec.
... The terms of service could specify that the credential is
only valid when presented by the subject, but beyond that,
anyone can put something in the claims.
<dlongley> +1 to Joe, Chris, and Manu's comments so far
<DavidC> +1 to terms of use having a field to day this VC can
only be presented by the subject
<Zakim> manu, you wanted to say "happy to explore how someone
hands a credential to someone else using Terms of Use or 'Use
my Badge' credential"
manu: Going back to DavidC’s comment, that helpls focus. This
is about S!=H, then how does the verifyer know that the subject
allowed the new holder to hold it. I’m happy to discuss how we
do that.
... I think the solution is probably in a terms of use
expression, or just to have the subject issue a new claim that
the new holder is allowed to use it.
... “I authorize Z to carry credential Y”
<cwebber2> yeah I don't see why we couldn't set up a ToU that
says, A is saying B about C, but D is the one who will present
it and counter-sign that they're the holder
<cwebber2> that's a case where the subject is not the holder
DavidC: I gave a couple of ways to do this, which included such
a mechanism, so the text is in. If we remove delegation and the
recursive delegation, maybe that will be sufficient.
<dlongley> +1 to David Chadwick's suggestion of using a second
credential and removing delegation/recursion
DavidC: I also like Joe’s suggestion about the terms of use
describing such limits.
<manu> +1, that general approach would work for me... although,
I'd like to understand the critical use case that requires this
feature...
DavidC: I think we’ll need some flags or fields in the data
model to conrol this.
<manu> I think that the default should be "credential can't be
used by anyone other than the subject"
cwebber: I don’t see how the workflow manu presented, where D
countersigns won’t work. It’s true you’ll need to reissue if C
had told D they wanted them to hold onto it; I think it would
work.
<manu> and if you want to change that default, you can do so
via Terms of Use or another credential.
DavidC: If you consider a passport, I can’t go to the
government to allow my wife to use it. I don’t think it’s
always practical to go back to the issuer. Control belongs to
the subject, not the issuers.
<cwebber2> yeah power of attorney gets back to authorization
stone: consider power of attorney, where I grant my spouse
permission to sign a mortgage on my behalf. I could issue a
claim to do this, and she could use this to complete a
transaction.
... Is that sufficient? Seems like the data model supports
this.
TallTed: self sovereign does not put the individual in control,
it means that the certificate is not an authority for all
things, but may be for some things.
... Considering power of attorney, these things usually don’t
have time limits, usually valid until revoked. I’m concerned
that these discussions cycle back into the same discussion.
... The idea of issuing a second credential makes the most
sense to me.
<DavidC> +1 to TallTed
<dlongley> +1
<manu> +1 to TallTed
TallTed: If the issuer disallows that, it needs to be taken
into consideration.
<stonematt> +1
<Zakim> JoeAndrieu, you wanted to talk about "permission" to
use a statement of fact
JoeAndrieu: VC are staements of facts, which could be used to
represent authentication, but that’s in the claims domains. You
can use VC to construct all sorts of things in the claim space.
... Limitations on using VCs themselves are challenging. A
credential might be used to get into a bar, and a bouncer may
further provide that to someone else for auditing.
<Zakim> cwebber, you wanted to try to wrap up on proposal to
leave out authorization from VCs
<manu> +1 to cwebber -- we keep going back to authorization.
cwebber: We did diverge back into authorization with power of
attorney, but we’re starting to converge on moving
authorization out of VCs.
<JoeAndrieu> +1 for keeping authorization out of the VC
top-level vocabulary
stone: we’ll bring it back next week.
<dlongley> +1 to Joe
<manu> +1 to JoeAndrieu
<Zakim> TallTed, you wanted to say "statements of fact" is
always problematic -- these are assertions, always and only --
facts are different things
TallTed: these are not statements of fact, these are
assertions. You can verify that something was said, but not
that it’s true.
<dlongley> +1 to TallTed ... i think we're all in agreement,
not facts :)
TallTed: All we can verify is who said what, not the what
itself.
<JoeAndrieu> +1 agreed, TallTed. I should have been more
careful with my word choice.
<stonematt> +1 TallTed
<manu> +1 to TallTed
<DavidC> I will redo Subject NE Holder PR and remove the term
delegation, and talk about handing on a VC
<identitywoman> bye everyone. looking forward to participating.
<cwebber2> +1
<dlongley> +1
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [15]scribe.perl version
1.152 ([16]CVS log)
$Date: 2018/07/31 16:27:57 $
[15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[16] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 31 July 2018 16:34:57 UTC