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? ✪
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? ✪
... 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.
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? ✪
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 ✪
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. ✪
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 ✪
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.
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." ✪
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. ✪
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 ✪
Ryan Grant: Nathan, thanks for thinking about the impedence issues ✪