- From: <msporny@digitalbazaar.com>
- Date: Tue, 19 Sep 2017 14:18:40 -0400
- To: Credentials CG <public-credentials@w3.org>
Thanks to Heather Schlegel for scribing this week! The minutes for this week's Credentials CG telecon are now available: https://w3c-ccg.github.io/meetings/2017-09-19/ 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 2017-09-19 Agenda: https://lists.w3.org/Archives/Public/public-credentials/2017Sep/0050.html Topics: 1. Introductions and Reintroductions 2. Proposed changes to DID Spec Overview 3. DID Spec Discussion Organizer: Kim Hamilton Duffy and Christopher Allen Scribe: Heather Schlegel Present: Heather Schlegel, Drummond Reed, Daniel Buchner, Christopher Allen, Manu Sporny, Dave Longley, Ryan Grant, Kim Hamilton Duffy, Joe Andrieu, Adrian Gropper, Mike Lodder, Christian Lundkvist, Nathan George, Chris Webber, Andrew Hughes, Moses Ma, David I. Lehn, Brent Zundel, Adam Migus, Chris Chapman, Jim Goodell Audio: https://w3c-ccg.github.io/meetings/2017-09-19/audio.ogg Heather Schlegel is scribing. Topic: Introductions and Reintroductions Heather Schlegel: Hi, Heather Vescent - I have been lurking on the Verifiable Claims and Interledger lists, other W3C lists as well. [scribe assist by Manu Sporny] Heather Schlegel: I thought I'd drop in and see what is going on - I'm a futurist researcher, study digital identity, security, money and transactions, a lot of that kind of stuff. [scribe assist by Manu Sporny] Drummond Reed: Heathervescent has been part of the IIW community for many years. She also produced a 7 minute film about IIW. Daniel Buchner: I'm wondering if there is a lot of discussion related to ActivityPub in this group? Christopher Allen: There was a proposal for rebooting web of trust, unable to attend this call. supporting efforts in credentials, but they have their own community group meeting, learning how to incorporate verifiable claims and DID stuff they have in their proposals to ActivityPub Manu Sporny: Looking at doing coordination with activity pub. Chris Webber is the best person to contact for this. (Daniel was the previous speaker) Drummond Reed: What is ActivityPub? Brief description? Dave Longley: Drummond, here's the spec https://www.w3.org/TR/activitypub/ Daniel Buchner: Ok, well I'm at Microsoft now, but when we were working on social web stuff at Mozilla, we tried this approach and ended up wanting to do something more generalized, which is what we're working on now. So, wanted to engage on the ActivityPub stuff to discuss. Ryan Grant: Is digital bazaar DID spec on the agenda today? Kim Hamilton Duffy: Yes, it is, Ryan. Christopher Allen: Covering DIDs all day Drummond Reed: I can also give an update on the DID Primer. Kim Hamilton Duffy: New name and mission statement discussion. ... action item assigned to Manu: follow up with Dan Larimer at EOS Manu Sporny: Still in process, they'll join when their schedule frees up a bit. Topic: Proposed changes to DID Spec Overview Kim Hamilton Duffy: DID review: have a lot of people to talk about the broader impact changes for the spec. Manu will drive this. Kim Hamilton Duffy: Manu's pull request, which attempts to address a number of issues: https://github.com/w3c-ccg/did-spec/pull/22 Manu Sporny: The issues are being triaged here: https://github.com/w3c-ccg/did-spec/issues/21 Kim Hamilton Duffy: You can preview the proposed changes here: https://msporny.github.io/did-spec/ Manu Sporny: Quick update on DID spec. ... triaged number of issues around DID: e.g. authentication. Do we talk about digital signature, biometric proofs, discussion around the security model for DID document. ... exploring moving to capabilities security model. ... express authentication credential public/private biometric keypairs ... best way to move forward on all these issues. Manu Sporny: Proposed update to the DID specification: https://msporny.github.io/did-spec/ Manu Sporny: There is a complete example here: https://msporny.github.io/did-spec/#appendix-b:-the-generic-did-context-for-json-ld ... Link is the new proposal... supports all the use cases we've always discussed. ... addresses the use cases with simplified concepts. Dave Longley: Authentication/authorization semantics are more explicit with the new proposal Manu Sporny: There are those of us implementing these ideas ... have learned from our past experiences and incorporating our learning into it. Topic: DID Spec Discussion Ryan Grant: Do you cover org control, manual re-implementation for ssi contacts. affirming a change for users on different teams. is it supported? Manu Sporny: Yes. ... in the new spec it is the authorization field. Heather Schlegel: OrControl and AndControl, section 6.5 of the old spec [scribe assist by Ryan Grant] Manu Sporny: Future things we submit, proofs on various blockchains (eth, etc) Ryan Grant: How do I do that. Manu Sporny: Look at Appendix B. Joe Andrieu: Would be great to explain the logic. Manu Sporny: Will update the spec text. Manu Sporny: I need to understand more before approving. More intermediate text may be required.' [scribe assist by Ryan Grant] Drummond Reed: Raising issues not addressed: (didn't catch everything) Suggestion: we look at the architecture first. ... decided the tradeoff between arch, then use cases, then update the text. Manu Sporny: +1, Totally agree w/ Drummond's approach to updating the spec... think its the right approach. Christopher Allen: Is there a place that talks about issuer proofs? Manu Sporny: Yes. Issue credential capabilities. Self issuring. In Appendix B. Christopher Allen: General architecture is good. Mark Miller will be at Rebooting/Boston. Drummond Reed: Link to the Google doc draft of the DID Primer: https://docs.google.com/document/d/1BsRZT4quGzvr1xVxTQSKB4dR9p95FLAgYhtaI3Yk4gU/edit# Drummond Reed: Feedback and input into the DID Primer is welcome from all DID community members. Adrian Gropper: One concern. Re: recovery of credentials that are non repudiable. Christopher Allen: Not the DID spec that does that. ... goes on to describe other options. Drummond Reed: +1 To nage's concern to not entangle policy beyond simple universal semantics Mike Lodder: +1 Nage Drummond Reed: Capabilities are good but the more system-specific they become, the more complex the whole space becomes Manu Sporny: Responding to Drummond. It's not in the spec yet. ... DB thinks we do need that. Concerned/working through w/ unintended consequences. Daniel Buchner: Microsoft might be using DIDs in production sooner than later. Drummond Reed: I'm coming at this as much from a key management requirements for DKMS as for the requirements for verifiable claims. For DKMS we need very simple, extensible key description semantics that enables key owners to identify and describe their keys. Christian Lundkvist: Question about the updated terminology: authentication and authorization. Drummond Reed: An inititial reaction is that it's out-of-scope for the DID spec to define the semantics of "authentication" and "authorization" at any scope beyond interaction with the target ledger for updates to the DID document itself. Manu Sporny: Should never use some authentication credentials on the web and use the same credential to do other things (loan). ... "authentication credential" there are many ways to authentication and there will be many ways to authentication (web/biometric) ... keys shouldn't be doing double duty. Drummond Reed: I want to clarify that Digital Bazaar has proposed a set of changes. They are not "changes" until they are accepted by the consensus of the group. That's the whole point of this process. Christian Lundkvist: Two buckets of keys. Should there be a general bucket? Ryan Grant: https://github.com/w3c-ccg/did-spec/compare/gh-pages...msporny:gh-pages Drummond Reed: I think the larger architectural issue here is whether the DID spec should be "key-description-centric" or "key-action-centric". Manu Sporny: Authorization bucket, these are the entities that are allowed to do things on behalf of me (delegation) and the ways they can authenticate are x,y,z. Drummond Reed: Manu is arguing for key-action-centric, i.e., keys are annotated for what they can be used for. So it starts to embed key usage policy in the key descriptions. I'm worried about that because of the slippery slope that @nage refers to. Nathan George: Unfortunately the separation of concerns here isn't always clean (this relates to ledger membership and transaction endorsement) which depending on how the ledger works muddies this water Dave Longley: This sounds like we should hash it out in a specific github issue Kim Hamilton Duffy: +1 To dlongley Drummond Reed: Ok Manu Sporny: General design: make the buckets do only one thing. So there may be a need for a new bucket for new things. E.g. use case to issue credentials/ this is how you can authenticate of the DID. If you want to modify, these can do it. But, allow these keys have access to a house, not necessarily something you put in the DID document. Might be in a service provider (e.g. Nest) ... need to be specific about what these fields can do, so we don't create security vulnerabilities. Nathan George: Consider the endorsement/ordering model of something like Hyperledger Fabric compared to the smart contract model of something like uPort and negotiating the semantics of key posession vs authentication (hopefully) becomes more clear Dave Longley: "Authorization" field tells you how to construct a "capability" that you can submit that will let you do something specific. .... authenticationCredential field lists verification information for authenticating as the entity that a DID identifies Drummond Reed: I definitely would like an education on "ambient authority security issues" Christian Lundkvist: I'd like to make the system flexible for permissionless innovation Dave Longley: "Authorization" field can therefore specify a capability like "issueX" Kim Hamilton Duffy: Like this approach. The unclear part of DID spec, is around service points. Nathan George: Credential repository in the DID Document??? (this needs to be explained and defended more directly) Drummond Reed: To Kim's questions, no, service endpoint definitions are supposed to be independent of any particular DID method. Each service type should be described in a separate Service Description. Nathan George: Again adding semantics into the DID Doc will cause least-common-denominator semantics issues Dave Longley: Nathan, yes, original data model design included the ability to include credentials in the DID document ... DID document can be a "Verifiable Profile"/"Entity Profile" in the VC model. Nathan George: Ugh Manu Sporny: +1 For putting service links in service description specs Dave Longley: +1 Manu Sporny: So you can use them across all DID Documents... Nathan George: I believe that most semantics should be moved to service specs and handled there, putting them in the DID Document means that semantics must be supported in some universal way (including to everyone who can see that document) Nathan George: If you put it in a service then the service can discriminate depending on who is talking and why Nathan George: That interaction is taking place Drummond Reed: Need a consistent way to describe keys associated with the DID. And we won't know all the use cases for them. Daniel Buchner: There is certainly a concern around what keys can be used for what and when. Manu Sporny: +1 To DID Document Mike Lodder: Yes DID document +1 Dave Longley: +1 To DID Document Kim Hamilton Duffy: +1 Joe Andrieu: +1 Chris Webber: DIDDoc Chris Webber: +1, DID Document seems good to me :) Nathan George: Every ledger who tries decentralized identifiers, they have different ways their ledgers work. transaction semantics bleed into the DDO objects and interoperability is difficult. Manu Sporny: +1 To not letting transaction semantics bleed into DID spec.... ... there are other ways of authorization than key, need to make sure doesn't bleed into authorization or transaction semantics. What is the decoupling btwn ownership of Identity and transaction semantics. Drummond Reed: All good. Kim and Christopher, for the minutes, I would like to note that it appears we have general consensus around moving from the term "DDO" to "DID document" (or the verbal shorthand "DID doc"), and that we will start using this in the spec and documents about DIDs such as the DID Primer. Joe Andrieu: I'll give my report here: No real progress since last report, but I would like to get feedback at RWoT on a first draft of the 15 steps in my engagement model. That's my current deadline for creating something to get initial feedback on. Christopher Allen: Authorization/authentication not in the DID doc, but somewhere else, that is also important. Christian Lundkvist: Very good points by nage - a lot of times what can be expressed in the "authorization" parts in the DID doc cannot be enforced by the ledger Dave Longley: "Proof of ownership" suggests ambient authority ... better to be really specific about what one is authorized to do once they have authenticated using a particular credential. ... Services can be static document and not always Rest or other Api. Kim Hamilton Duffy: JoeAndrieu - is it the usual link? I'll dig it up Dave Longley: And to christopher's current point ... "particular credential" doesn't just mean "digital signature using a key". ... not everything is going to be a simple signature. new security standards, there are new things that don't have traditional... btc block, some hashes, composite things acting as a signature. Joe Andrieu: Is there a usual link? Christian Lundkvist: A global state machine puts you at an advantage for coupling semantics into this problem, but introduces interesting challenges around disclosure [scribe assist by Nathan George] Dave Longley: So the capability model we're going for is: "the DID doc says these are all of the capabilities a client can construct ... if you're able to construct these (you have the necessary credentials), then you have the authority to use them to do things." Kim Hamilton Duffy: Joe Andrieu, this one? http://legreq.com/files/WoT.VC.EngagementModel.pdf Joe Andrieu: There's nothing yet ready to review. ... biometric as part of a series of authentication methods. Nathan George: The debates around system identities vs transaction identities at Hyperledger have convinced me that keeping identity semantics different from credential semantics different from ledger transactions is going to either save us or condemn us Joe Andrieu: Will have stuff to review at Rebooting Web of Trust. Drummond Reed: @Dlongley I agree with the general pattern of 1) apply authentication policy followed by 2) apply authorization policy. But I'm arguing that those two subjects are so rich and varied and evolving that we should limit the scope of the DID spec to: 1) standardizing extensible key descriptions (for any purpose), 2) then defining a small set of SPECIFIC authentication and authorization policies that can be applied to DID document operations. Dave Longley: "Keys" may not even come into the picture (Christopher's point), so we have to be careful with that. Drummond Reed: Made points in the chat comments. Joe Andrieu: +1 Drummond. DID authorizations should be wrt to the DDO / DID Doc only Nathan George: I agree identity semantics are not the same as key posession (but can be easily confused by systems that don't need a difference) Joe Andrieu: Agree that authorizations should always be related to the DID doc itself or the entity the DID refers to (this is Christopher Allen's use case for authorizing issuance). [scribe assist by Dave Longley] Ryan Grant: Question: is there an intention to move away from the 'writeAuthorization' field? Drummond Reed: @Dlongley Yes, replace "keys" with "proofs" in everything I said. Christopher Allen: Don't forget to register https://www.eventbrite.com/e/rebootingweboftrust-design-workshop-v-fall-2017-in-boston-area-usa-tickets-34984665075 Manu Sporny: Yes, no more 'writeAuthorization'... just 'authorization' and capabilities that entities have IF they provide appropriate proofs. Drummond Reed: I disagree - that's dictating policy. Thanks all. Nathan George: Ultimately an oracle of truth needs to validate the authorization, which is where the semantic barrier between the DDO Doc and the ledger transactions breaks down Nathan George: We need some time to let that cook so we don't introduce too much policy where mechanism is enough [SIP/sip.linphone.org-0000030f], DanielBuchner [SIP/69.65.34.216-00000310], Drummond [SIP/69.65.34.216-00000311], nage [SIP/sip2sip.info-00000314], kimhd [SIP/69.65.34.216-00000317], Christian_Lundkvist [SIP/69.65.34.216-00000318], rgrant [SIP/69.65.34.216-0000031a], AndrewHughes [SIP/69.65.34.216-0000031b], heathervescent [SIP/69.65.34.216-0000031c], JoeAndrieu [SIP/69.65.34.216-0000031e], AdrianGropper Christian Lundkvist: Nage - agreed with the authorization stuff [SIP/sip.linphone.org-0000030f]. [SIP/sip.linphone.org-0000030f] has left the conference. Ryan Grant: Nathan, thanks for thinking about the impedence issues
Received on Tuesday, 19 September 2017 18:19:08 UTC