- From: W3C CCG Chairs <w3c.ccg@gmail.com>
- Date: Thu, 20 Feb 2020 15:54:58 -0800 (PST)
Thanks to Dmitri Zagidulin for scribing this week! The minutes for this week's Credentials CG telecon are now available: https://w3c-ccg.github.io/meetings/2020-02-18/ Full text of the discussion follows for W3C archival purposes. Audio from the meeting is available as well (link provided below). ---------------------------------------------------------------- Credentials CG Telecon Minutes for 2020-02-18 Agenda: https://lists.w3.org/Archives/Public/public-credentials/2020Feb/0044.html Topics: 1. Introductions and Re-introductions 2. Announcements and Reminders 3. Progress on Action Items 4. Credentials vc Capabilities Organizer: Christopher Allen and Joe Andrieu and Kim Hamilton Duffy Scribe: Dmitri Zagidulin Present: Christopher Allen, Joe Andrieu, Manu Sporny, Orie Steele, Adrian Gropper, Dmitri Zagidulin, Dave Longley, Sumita Jonak, Steven Pattison, Justin Richer, Nate Otto, Drummond Reed, Chris Winczewski, Jeff Orgel, Kim Hamilton Duffy, Ganesh Annan, Ken Ebert Audio: https://w3c-ccg.github.io/meetings/2020-02-18/audio.ogg Joe Andrieu: Shoot. My onsip isn't working. Trying a reboot. BRB Christopher Allen: Good morning everyone Christopher Allen: Anyone up for scribe? Orie Steele: Can someone share the sip web client url? I have a new computer... Dmitri Zagidulin is scribing. Christopher Allen: <Opening IP notes> … anyone new to the call? Topic: Introductions and Re-introductions … re-introductions? Dmitri Zagidulin: Working in decentralized identity spect with digital bazaar, also involved in other projects solid, did:web, and other other specs [scribe assist by Christopher Allen] Topic: Announcements and Reminders Joe Andrieu: Reminder about the DID Resolution calls on Thursdays … General reminder - please read and comment on this publication from NIST Adrian Gropper: Zero Trust Architecture https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207-draft2.pdf Topic: Progress on Action Items Joe Andrieu: https://github.com/w3c-ccg/community/issues?q=is%3Aopen+is%3Aissue+label%3A%22action%3A+review+next%22 … since it's likely of interest to the people in this group … issue 1 - SIP is not working? Christopher Allen: A number of us are having challenges on making SIP work on various platforms Kim Hamilton Duffy: Dmitri presented the did:web method during last week's VC for Education Task Force meeting. There's a lot of interest in hearing the recording for it (so I backfilled it), and it's available here: https://w3c-ccg.github.io/meetings/2020-02-10/ … it would be great if somebody could write up instructions / tips and tricks … looking for volunteers Joe Andrieu: Didn't we used to have a blurb, on SIP instructions? … if we have one, I'll add a paragraph about Windows Dmitri Zagidulin: Where would be a good place to put this instruction docs? Christopher Allen: On our repo, ultimately. short term, Google Doc is fine Kim Hamilton Duffy: This: https://w3c-ccg.github.io/connecting.html Kim Hamilton Duffy: Please feel free to add / edit this connecting document Joe Andrieu: Second issue - Crypto Suite Specifications … kimhd? or ChristopherA? Christopher Allen: There was a suggestion to close it. But I didn't want Orie's comments on the issue to disappear, if we closed it … so we should also add this to our repo's homepage Joe Andrieu: Orie just closed this, and put a link to the CryptoSuite Registry Orie Steele: We should link to the registry, and the registry should link to implementations... Christopher Allen: That helps, but I'd also love to have links to various implementations, as well Orie Steele: In this case it does … it would be helpful to point newcomers to the CCG to the spec / implementations Manu Sporny: I'd like to highlight that there's a lot of stuff happening with the CryptoSuite stuff, thanks to Orie's efforts … as a related announcement to the group: There's a lot of work happening in this space; it's very active … we're trying to figure out how the registries work with the DID Core spec … so, if you're interested in this, please do track the DID Registry repo Manu Sporny: https://github.com/w3c/did-core-registry/pulls?q=is%3Apr+is%3Aclosed … since a lot of activity will be done there Manu Sporny: https://github.com/w3c/did-core-registry/issues Joe Andrieu: Q … which also relates to this specific issue Christopher Allen: The work that's going on in the DID Core Registry is fabulous … <garbled> … I'd like to see volunteers for managing repos, registries, implementation lists … to make this CCG more friendly for newcomers. So, we need an entry point Orie Steele: I really like the awesome github repo pattern: https://github.com/sindresorhus/awesome Orie Steele: For example Joe Andrieu: Orie - does the CryptoSuite spec list implementations? Christopher Allen: Will do … agree with Chris, it'd be great to have someone curate a list of implementations … so, ACTION item for Chris - raise an issue requesting volunteers / implementation list Christopher Allen: Closed ok … that's it for the front matter. Next up, technical talk … on the difference between Capabilities and Credentials Joe Andrieu: https://github.com/w3c-ccg/meetings/blob/gh-pages/2020-02-20/credentials_and_capabilities.pptx … before I go into the presentation, I believe we're scheduled next week to have a discussion on Capabilities, Lightning Networks and Macaroons Christopher Allen: Yes … we have someone who's done an interesting demo using the Lightning Network … (it's a payment channel for microcurrency, leveraging Bitcoin) … and there's new ability to use macaroons that provide bearer authority (to read content, etc) that can be tied to payment network … macaroons being very similar to zCaps … there's the ability to make it atomic (the payment gives you the capability) … I think this may be relevant to our broader architecture … either to the future architecture of zCaps, or in general Topic: Credentials vc Capabilities Kim Hamilton Duffy: https://github.com/w3c-ccg/meetings/blob/gh-pages/2020-02-18/credentials_and_capabilities.pptx?raw=true Kim Hamilton Duffy: See my link Ganesh Annan: The link kimhd worked Joe Andrieu: So, both Credentials and Capabilities are digital objects … transmittable over any comm channel, and both use cryptography for security assurance … used to enhance service, customize features, etc … Anyone can make a verifiable statement about anything, on any subject. … a traditional use case is - digital credentials (Passports, licenses, etc) … But VCs can be issued by anyone. Receipts, wills, business cards, notes to mom, school sick notes for children … VCs democratize the ability to produce hard-to-forge credentials … The key point to remember - they don't verify the _truth_ of the statement … they don't say, for example, 'The Sky is Blue'. Instead, they verify 'Joe says: The Sky is Blue' … so, they are statements … so, what a verifier does is - go through various checks. … do they trust the issuer of the statement? … what privileges and services are appropriate for that presenter, based on that statement … so, it's the verifier's business logic … to see what actions can be taken as a result of VCs … What I'm calling Directed Capabilities (previously I referred to them as Digital Capabilities) … these are based on 1986 (?)'s Object Capabilities … (currently also referred to Authorization Capabilities) … there is no clear standard yet. One of the approaches is zCaps, a work item of this CCG, … developed by Digital Bazaar, … which implements capabilities on top of VCs … for those familiar with CHAPI (Credential Handler API) — you can use zCaps through CHAPI, sort of what they were built for … so, Directed Capabilities is a generalization of this concept .. DCs give the ability to perform privileged operations Manu Sporny: HTTP Signatures spec, which does use ZCAPs (in experiments): https://tools.ietf.org/html/draft-richanna-http-message-signatures-00 Manu Sporny: ZCAP spec - https://w3c-ccg.github.io/zcap-ld/ Manu Sporny: All based on object capabilities. … the important thing about Directed Capabilities is - they are issued by the same authority that is accepting the credential … the process of invoking the capability is what gives an actor the authority to take that action … DCs can be set up also to have Delegation, Revocation … because these are also digital objects, they can be managed alongside VCs, in digital wallets … the idea being that in your wallet you'll have a mix of VCs and DCs … so, you'll have credentials, and then capabilities to trigger various actions … so, with DCs, the privileges are _explicit_ … which is a bit of a shift from most ACL-based paradigms … the inspection of the capability can directly reveal what is invokable … it's easy to audit "what does this let me do" … and if the DC is valid, non-revoked, and you invoke it, the contract is that the provider makes the action happen … important: these are completely independent of traditional forms of identity (DIDs, etc) … so, the atomic manifestation is - the ability to invoke an individual capability … so, the DCs are self-contained (not dependent on ambient context) … the canonical example of a Directed Capability is a physical car key … which is a capability that lets you open and start a car … it does not depend on the identity of the user … you don't have to register it with a registry, or anything like that … so the possession of the key IS the embedded authorization … so, for example, in court, if you accuse your child of stealing your car, but you gave them your key, the case won't work — the possession of the key is the authorization … so another example of an Attenuated capability is a Valet Key … so, it has a subset of permissions of a regular key … DCs are Revokable … you can revoke / disable the authorization remotely, without tracking down the actual capability … and they are Losslessly Delegatable … at low marginal cost … thirdly, you can Attenuate these capabilities in any number of ways (as allowed by the Issuer) … the issuer gets to set up the framework of attenuation privileges, but after that, it's completely under the holder's control … so, issuer, when creating a DC, specifies the Scope of the capability … and set up the rules fo rrevocation, delegation and attenuation Kim Hamilton Duffy: Should Capabilities have a type? (ref https://w3c.github.io/vc-data-model/) there's some commonality between this and VCs, and I see why you modeled it differently, but in a few years, will we end up with a range of Verifiable "Things … so, if you wanted different actions based on day of the week or time of day, that's possible. But key thing is - the issuer has to support that action … but once the issuer sets up the pattern, after that it's entirely under control of the DC holder, operationally … all of that supported by cryptography … so let's look at an example of a digital car key … so now, we can attenuate it in interesting ways. For example, disable trunk access. Or, further, do not allow the car to start. (so, the key can only open the door and that's it) … you can have limits on location (so valet can't take car on joyride) Kim Hamilton Duffy: Meant to link here: https://w3c-ccg.github.io/zcap-ld/. there are some elements of VCs that maybe are also needed in zcaps. Joe mentioned issuer... … obviously this is limited by car features (like onboard GPS), so you can't arbitrarily make up limitations … some architectures require 'phoning home' to the issuer. but other architectures do not … So, imagine that a bank gives you a Directed Capability … I can delegate them to my accountant, bookkeeper, controller, and so on. So they can have access to my account without me sharing my login & password to the actual account … you can attenuate these delegations in interesting ways. Read-only. Or, read only a subset or a summary of my accounts (say, a monthly summary only) … again, the issuer (bank) has to _support_ these capabilities … and either the bank or the resource controller can revoke the capability at the same time … another nice thing about DCs is - if I delegate one of these to my accountant, he can delegate it to his assistant … so, I can either delegate access to a firm, or to a person, but then it's delegatable (without me getting involved) … I could restrict it and not allow delegation, of course. but it's easier on me in many cases, if I don't have to be involved … key is - upon invocation, the entire chain of delegation is presented … again, unlike typical ACL architectures Orie Steele: I'm not sure its practically possible to restrict delegation.... technically.... … you could track the audit trail exactly who authorized these capabilities, and who delegated, and so on … there's limitations on identifying people by keys and so on, but the auditability is there … slide 21 - Credentials vs Capabilities … how I think of these things … so, Credentials - they're basically statements. you can present em anywhere, and the business rules of the verifier manage interpretation. … Capabilities - the business rules are set up during creation, by the issuer … and delegation mechanisms are also constructed at time of issuance … both are revokable … credentials are not delegatable or attenuatable … like, 'Joe says sky is blue' is just a statement, you can't really delegate it … whereas Capabilities - are delegatable etc … the best use of Credentials is — authoritative credentials or identity proofing … like, KYC (Know Your Customer) type of use cases … Capabilities, on the other hand, are ideal for authorization and delegation Orie Steele: It's not practically possible to stop delegation (you can share/proxy keys/proofs), but liability changes when you get caught (either you delegated in an authorized way or you didn't .. the latter being potentially more dangerous for you) [scribe assist by Dave Longley] … so, once I'm onboarded onto a service (with credentials), then I can manage authorization, with delegations and so on, using capabilities … so, that's the short summary. Questions? Orie Steele: Awesome presentation, excellent job. … one of the things I learned at IIW is that the concept of restricting delegation is tricky … has there been additional knowledge / discussion since then? Joe Andrieu: Great question. So, first, no keys are shared (in the delegation of capabilities) … you could _simulate_ delegation by actually giving somebody a key. But capabilities allow you to delegate without that … you're recording that you authorized another keyholder to do stuff … so, a capability may say "my DID authorizes their DID to perform these actions" … importantly, although it's not possible to prevent delegation at the time, I can state that the capability is marked non-delegatable … which matters when you examine the audit trail … so, if delegation is disabled on the third step, and the third party further delegates it, it makes the whole chain invalid Orie Steele: I meant more about car keys — once you give a key, you can't really restrict its delegation after that … as far as VCs and DCs, they don't prevent somebody willingly sharing their keys Joe Andrieu: Q Christopher Allen: Of course, if keys are compromised, all guarantees are off. You can give away or share your private keys Kim Hamilton Duffy: I thought Orie's point is less about key sharing and more about further delegation … the key is setting up incentives, so that it's against the interest of people to share their keys … plus, legal liabilities after the fact … preserving the relationship with the issuer. … similar to how today, you can give your username & password to your accountant, even though the bank explicitly says not to share em … although Capabilities are similar to VCs, in some of the details, they are definitely different … but it's clear that all the work we put into the VC data model, we can use that, and build DCs on top of em … also, the DC may not be the sole thing that you present. Instead, you could present a number of capabilities PLUS various VCs … like proof of payment … (and next week, we'll talk about atomically binding payment to capability) Adrian Gropper: I'd like some clarity to — "it's only invoked at the issuer's service", and the other is "there's no phone-home requirement" … the context is the Alice To Bob use case Adrian Gropper: https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/topics-and-advance-readings/delegated-authorization.md … where the issuer is Alice, but the capability is going to be exercised at Alice's chosen service providre … that she has chosen as a processor … I put in a link to this four-way chain of agents … that I use to describe this usecase Christopher Allen: An issuer can require that presentation of a capability can include a phone home or audit log home, etc. requirement. Remember, issuers consume their own capababilites. … and we have a number of delegation steps in that use case, for an agent scenario, that I hope we can map into the Capabilities model … and that includes this important ones, about different parties' wallets Joe Andrieu: It's a slight misnomer that Alice is the issuer in your example. It would be the Processor that's the initial issuer. which gives a capability to Alice, who can then delegate to Bob … the not phoning home is — Alice or Bob does not need to check with the processor during delegation or attenuation Adrian Gropper: Got it Joe Andrieu: Q Joe Andrieu: Next week, the Lightning Network! … and that's all! Kim Hamilton Duffy: Presennt+ bernhaard, chriswinc, drummond, fr33domlover, gannan, Gargro, heathervescent, identitywoman, JeffO-Stl, joel_, jonathan_holt, justin, ken, kimhd, llorllale, rory, smagennis, SRPattison, sumita, Tom_S__USAA_, tzviya, wayne
Received on Thursday, 20 February 2020 23:55:14 UTC