... In general, we should be thinking about things in terms of proofs because not everything will be a signature.
... especially when we start talking about privacy schemes
Manu Sporny: We need to figure out if anyone will oppose the change ✪
... this came about because the btcr hackathon raised a number of questions around "what about different ways of proving things?"
... we have three classes that don't all fit into signature
... First, signatures
... Second, from the Joram case, how do we use psuedonymous biometeric
... Thirds, then there are hashes that aren't signatures
... we have examples where it is a proof, not a signature
... so we might change from linked data signatures to linked-data proofs
... or, if that's too drastic, we could just change the linked data library to ALSO accept a proof field
... already discussed this with Dave Longley. It's not a big change from an implementation perspective
... Digital Bazaar is favorable towards proofs, happy to do first implementation
Christopher Allen: I'd also like to add there are a number of blinding proofs where you proof you have the information without revealing it ✪
Kim Hamilton Duffy: My interpretation was not so much that we need to update at the code/API level, but rather that we should refer to proofs instead of just signatures at the DID spec level ✪
... I didn't understand the separate signature and proofs field. Why would that be useful?
Manu Sporny: Why the low level change? Let me unpack ✪
Christopher Allen: Timestamps is a good example of a proof and not signature ✪
... We looked into that because all the code, all the data-model has a field called "signature" and you look into the signature to see if the data is valid or not.
... but there are other ways to check if the data is valid
... Christopher mentioned blind proofs
... if we didn't make this change, a future claim could have a biometric proof in the signature area. which is confusing.
... similar for blinding proof. Confusing to have non-signatures in a field named "signature"
... Also multi-proofs
... two things: you have to provide, e.g., a string from a hardware security module *and* something from a biometric mechanism.
... that's why we are moving towards a field that lets us put any of these types of proofs in there
Lionel Wolberger: Let me add zkstarks and starks ✪
Christopher Allen: It might be a helpful things for all of us to be more careful to think and talk about things as proofs, rather than signatures. ✪
... so shifting thinking could impact architecture, data-model, etc.
Chris Webber: I'm not sure those are the same thing? ✪
Drummond Reed: What is being proposed in terms of changes to the spec ✪
Christopher Allen: Wherever we have signature in a field name, think through whether or not it really is a "proof" instead. ✪
Nathan George: -1 To taxonomy change without more discussion (I'm feeling like there are some disconnects in how this being used by different systems, but perhaps I'm just not getting it yet) ✪
Manu Sporny: We are replacing the term where it makes sense. We need to think through the semantics of that, and add language about proof mechanisms. We have a list of what needs to be updated and are working on it. ✪
... This is a fairly broad change. Nathan would like to discuss this further.
... This will probably take a couple weeks to sink in
... Not sure I addressed Kim's concerns, but she's adding that to the tracker, so we can continue there
Drummond Reed: I get this is a broader change. I don't know if we are trying to close on these... ✪
... on today's call
Dave Longley: "What is the overarching goal on the call" ✪
Christopher Allen: Not sure we can close very much other than trivial details, but I would like to get these changes into a draft before RWoT ✪
... there's going to be live code and people registering DIDs, etc., I'd like the spec to be closer to much of our current thinking
... Trying to make it work (in btcr hackathon) taught us a lot. Would like to get same bump at RWoT
Drummond Reed: That doesn't make sense to me at all. ✪
Drummond Reed: There's a huge difference between ownership and control. ✪
... what we have tried to do, in this issue, is to highlight an alternative that makes it more clear what proofs are used to do what with the data in the DDO
... for example, we've separated the concept of authentication and authorization
... that's the primary change proposed to the DID spec
... rather than ownership/control, it's authN/Z
... that's what the discussion is about
... we think that's the better way to organize these
Drummond Reed: I get the difference between authentication and authorization - but those concepts operate at a higher level than DIDs ✪
Ryan Grant: I had some questions, here's how I got them answered ✪
... right to authorization (proof of control) should not need right to authentication (proof of ownership)
Drummond Reed: As soon as I heard that DID is talking about AuthN/Z, it seemed off ✪
... DID is about resolving a public identifier with a public key
... and the criteria for changing the associated DDO
... I have a feeling I don't quite understand the issue.
Ryan Grant: Rgrant summary 1/3: "writeAuthorization" (called "proof of control" in the DID spec) should not allow changing "authenticationCredential" (called "proof of ownership" in the DID spec), ✪
... Not sure I'm on the same page about that distinction. Afraid it may be confusing the purpose of DIDs.
Ryan Grant: Rgrant summary 2/3: ...because that violates the goal explained on page 10 of the spec, section 6.4, where entities assigned to help with key recovery can change the DDO's "proof of ownership" to ALSO allow impersonating the identity owner. ✪
Ryan Grant: Rgrant summary 3/3: as Section 6.4 explains, "Note that Proof of Ownership is separate from Proof of Control because an identity owner may wish to enable other entities [...] to update the DDO [...] without enabling them to prove ownership" ✪
Christopher Allen: If you look at our initial discussions, I coined the term control and ownership, with a warning that these might not be correct ✪
... the terms ended up confusing everyone
... when I think about them, I think about them in a cryptographic sense, rather than a more common definition
... the ability to update a record in the btcr spec has a particular approach
... the party that does that revocation cannot revoke credentials associated with the old ownership keys
Drummond Reed: I agree that the semantics associated with the words "control" and "ownership" now need to be replaced with terms that are more neutral with regard to the precise cryptographic primitives being managed in a DDO. ✪
... specific to the crypto
... So, the terms are confusing and they got picked up by non-bitcoin implementers in unintended ways
... I like the way the conversation is turning: here are some proofs and here are what those privileges are. What those are is still up for discussion, but this feels like a better way to discuss it.
Manu Sporny: I think that's a good way to say it. ✪
Drummond Reed: What I'm most passionate about is keeping the DID spec at the lowest, simplest level of associating an identifier with a public key and a service endpoint. ✪
... Even way back in the day, we conflated in original DID spec (that link is ancient). There's an access control field and a public key field.
... access control: write permission to DDO, but we used the public key for way to many things
... we are trying to identify known bad things, e.g., public key was a poor choice.
Dave Longley: The new general idea is `authorization` is a "capabilities list" ... where you indicate what authorities and "resources" (parts of the DDO) they can modify (and how) and what proofs can be used to authenticate those authorities (assurance level granularity) ✪
... for example, we are saying you shouldn't have a list of public keys, you should have a list of authentication credentials.
... that list of things is a way of creating proofs, not just a list of public keys
Drummond Reed: I simply don't agree with the point that the only use of a public key is authentication. ✪
... we are continuing to narrow what each of these fields is, and what it is doing.
... any time we have a field that lets us do two or more things, it means we haven't gotten the capability narrow enough, which leads to security vulnerabilities
Drummond Reed: The whole point of DIDs is to associate a public key with an persistent identifier. That's also the heart of DKMS. So conflating that with authentication is a major mistake. ✪
Drummond Reed: Authentication and authorization need to be clearly separated -- semantically -- so you aren't left to guess what the capabilities are -- or you aren't left guessing who has designated the resources that you want to do something with in software. [scribe assist by Dave Longley] ✪
... I don't expect this will be easy to grasp right away--it's taken us 3+ years to get this far.
Dave Longley: I'm in favor of describing the capabilities of a particular public key. [scribe assist by Drummond Reed] ✪
Christopher Allen: Drummond, to your comment, you can use public keys for lots of things, but you should be careful about that. ✪
... for example, use a different key for signing versus authentication.
Kim Hamilton Duffy: +1 To the capabilities approach. I agree with Manu that this is increasingly seen in implementations and standards -- primarily for the precision and composability it enables ✪
Drummond Reed: Ok, that's what we're experimenting with modeling. [scribe assist by Dave Longley] ✪
Nathan George: I like the idea that there is a flexible construct for non-key constructs for establishing control or ownership, still not conviniced that thing is a "proof" ✪
... we should be explicit about the different functions and how they are used differently.
... if you choose to use the same proof for multiple privileges, that makes it easier for a security person to evaluate the risks of those choices.
Christopher Allen: Drummond, it is particular relevant to the Sovrin use case, who will be doing a variety of proofs beyond public keys ✪
... the purpose of the DID is to resolve a public identifier to a set of endpoints to solve a problem
... Key ownership definition is important, and its good to understand what the keys are used for
... large question is are DIDs about endpoint discovery or is it pulled in other directions
... Let's NOT overcomplicate this
Dave Longley: "You want to do" ... "you" are the actor, how do you authenticate that it's you? ... it's not the "key" that is acting -- so the "key" is an authentication credential. [scribe assist by Dave Longley] ✪
Christopher Allen: Agreed with general push. The challenge is that you are using public keys as a heuristic that has worked in the past ✪
...and we may not be able to keep doing it that way
... CL keys for issuer proofs, but all of that blinding technology can potentially be applied at the DID level
... To future proof, we need to explicitly say what these things can and can't do.
Kim Hamilton Duffy: Per discussion on this thread https://github.com/w3c-ccg/didm-veres-one/issues/1, I think we are leaning towards finding a minimum viable set of capabilities for DID spec. Fine grained capabilities are more suited to extension specs as an added bonus ✪
Manu Sporny: I think we're aligned. We want the spec simple and cover all use cases ✪
Drummond Reed: I'm not sure I agree that the DID spec and DDOs need to say what a particular key "can and cannot do". That's trying to turn DDOs into a policy description language. I feel very strongly that we need to keep it limited to key descriptions. ✪
... Drummond, you said DDOs are about exposing keys. We are moving beyond that, but in way that lets us do more than just keys.
Nathan George: Concerned about leaks about semantics as we move forward. ✪
Drummond Reed: If we're going talk about the DID spec "doing something more than just keys", then I want to understand very, very explicitly about what "more" means, and why. ✪
... want to make sure we don't create confusion with statements like "this key is valid, but only when you do X"
... that's when we step into the abyss
Drummond Reed: I would dramatically prefer to keep anything that gets into claims or policy description in another spec. ✪
Nathan George: An example of "more than keys" would be an identity for a distributed ledger where the leger can use its consensus signed state to present claims and proofs collectively (BLS signatures) ✪
Drummond Reed: +1 To keeping the DID spec to *minimal possible info* required for bootstrapping into other descriptions/interactions. ✪
Christopher Allen: Done for the day. Next week more DIDs! ✪
... the 26th is the last week before RWoT
Dave Longley: Are you available for short call after this meeting? [scribe assist by Ryan Grant] ✪
Drummond Reed: +1 To getting all requirements/issues for the DID spec (and any DID method specs) on the table this month before RWOT. ✪
... if you have something for the agenda, please let Kim & I know
Lionel Wolberger: Inventory & selective disclosure for the 26th ✪