The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2017-09-19

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
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:
Manu Sporny: The issues are being triaged here:
Kim Hamilton Duffy: You can preview the proposed changes here:
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:
... 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:
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?
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?
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.
Manu Sporny: Yes, no more 'writeAuthorization'... just 'authorization' and capabilities that entities have IF they provide appropriate proofs.
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
Ryan Grant: Nathan, thanks for thinking about the impedence issues