The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2017-09-12

David Chadwick: Sorry all, I am going to have to be chat only today as I cannot get SIP to work (and Kim can verify that!)
David Chadwick: I can phone from my house phone when I need to talk to a topic (but I don't think I am on an agenda item today)
Kim Hamilton Duffy:
Joe Andrieu is scribing.
Scribe on
Christopher Allen: Rebooting Web of Trust in three weeks.

Topic: Introductions and Reintroductions

Drummond Reed: The speaker's voice is very weak
Chris Chapman: Working with Scholarly Commons, we are trying to create an alternative system for scholarship and science
... interested in DIDs, Linked Data Signatures, and things like that.
Ryan Grant: I got involved in a prior conference. Helped with DID specification.
... Interest on the bitcoin side of things. Bitcoin method spec.
... also contributed to PGP comparison method
... more of a teaching example of things that RWoT is attempting to fix
... In Puerto Rico. Near miss from Hurricane Irma. Power back on this morning!
Joe Andrieu: +1 For surviving hurricanes
Christopher Allen: Mom is 1 month w/o power. Blockstream satellite down for 19 hours.

Topic: Action Items

Manu Sporny: Going down the bug list is a good plan
Drummond Reed: We have lots to talk about on the DID front to prep for the sessions we want to have at RWOT.
Christopher Allen: Privacy & Security of verifiable claims came up in VCWG call earlier
Drummond Reed: Yes, can barely understand Christopher
Drummond Reed: Yes, that's it, we've finally figured it out! Christopher is a Transformer!
Drummond Reed: That explains his supernatural powers
Christopher Allen: Also two work items from Joe and David (Lificycle)
Kim Hamilton Duffy: In advance of RWoT, we're going to be focused on DIDs.
... reach out to us if you want any meeting time
... we'll be doing that for data minimization
... other action items
... one assigned to me (KimHD) for propagating new name and mission statement
... Manu had action item to follow up with Dan from EOS
Manu Sporny: Still in progress
... Dan has the information he needs
David Chadwick: @ Joe, I would love to attend RWOT but have no funding alas
Kim Hamilton Duffy: Send Journalist outreach to mosesm (done)
Christopher Allen: Kim you can't hear us.
Christopher Allen: I'm back. On regular phone.
... When is our deadline for TPAC discussion to get into a 15 minute intro or whatever?
Chris Chapman: +1
Manu Sporny: They like to have agendas out at least a month in advance
... The Wed plenary meeting is done the day of.
... but we should have our ducks in a row.
... presentations, know what we are presenting, so we are stomping on each others toes
... if we can set an Oct 15 deadline for what we want to do
... for the actual face to face meetings, that should be a month out
... December 10?
... main thing is to figure out what we want to do that Wednesday
... we can meet for an hour and we are competing against everyone else. The idea is that we can pull other W3C members in
Christopher Allen: We'll add that as a deadline to complete after RWoT
Moses Ma: Send this to retired editor at Reuters. pulitzer winner. Interested and would like to contribute. Dealing with Irma aftermath
Christopher Allen: We have a sponsor who is renting a house with five rooms, especially for European visitors who have higher expenses
... also looking to E&Y for something similar
... if you are in need of financial assistance, be in touch with ChristopherA
Lionel Wolberger: Please add me to that list
Christopher Allen: Next on Agenda. Issue 21

Topic: Proofs vs. Signatures

... Manu has summarized which bugs should be first on our triage
... #15 Proofs/Signatures
... 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.
Dave Longley: +1 To taxonomy change
Drummond Reed: Question. Is this a matter of semantics about what we call this element? Or is there some other aspect to the issue?
Chris Webber: If we added blind proofs would we want a separate key property for blind proofs? [scribe assist by Chris Webber]
Christopher Allen: Manu described it fairly well.
Kim Hamilton Duffy: Got it Manu. I like the first proposal (everything is a proof, signature is a specific type)
Chris Webber: Iirc there's a vulnerability in RSA if you use the same key for encryption as in blind proofs? [scribe assist by Chris Webber]
... there are ways to handle signatures architecturally that are different from some of the other proofs
Manu Sporny: Cwebber, probably not, authenticationCredential would work for blind proofs as well... maybe... it depends!
Kim Hamilton Duffy: Manu, I'm updating the issue with a quick summary of this discussion
Chris Webber: Wait
Chris Webber: I meant blind signatures
Manu Sporny: Kimhd, Thanks!
... 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
... Next up: Capabilities security model

Topic: Capabilities-based Security Model

... in issue #11... there is discussion about how we are doing it,
Kim Hamilton Duffy: I updated the issue with (my understanding of) decisions we need to make:
... but we should probably restructure that. Thoughts, Manu?
Manu Sporny: This is one of the hardest discussions we're going to have.
... The current DID spec, as it stands, makes a distinction between ownership and control
Manu Sporny: Explain issue with current DID Spec:
... Dave Longley took some time this morning to unpack
... The problem with the current spec is that when you get to implementation, there is no difference
... anyone who has proof of control, has proof of ownership. that's just how it's defined.
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.
... We've had this issue for a while now.
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.
Drummond Reed: I think that helps.
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, 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