<scribe> scribenick: gkellogg

<stonematt> 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> 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> https://github.com/w3c/vc-data-model/issues?utf8=✓&q=is%3Aissue+is%3Aopen+no%3Aassignee

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