[MINUTES] W3C Credentials CG Call - 2017-09-12 12pm ET

Thanks to Joe Andrieu for scribing this week! The minutes
for this week's Credentials CG telecon are now available:

https://w3c-ccg.github.io/meetings/2017-09-12/

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-12

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2017Sep/0032.html
Topics:
  1. Introductions and Reintroductions
  2. Action Items
  3. Proofs vs. Signatures 
  4. Capabilities-based Security Model
Organizer:
  Kim Hamilton Duffy and Christopher Allen
Scribe:
  Joe Andrieu
Present:
  David Chadwick, Joe Andrieu, Christopher Allen, Drummond Reed, 
  Chris Chapman, Ryan Grant, Manu Sporny, Kim Hamilton Duffy, Moses 
  Ma, Lionel Wolberger, Dave Longley, Chris Webber, Nathan George, 
  Paul Simmonds, Adam Lake, David I. Lehn, Adam Sobieski, Adrian 
  Gropper
Audio:
  https://w3c-ccg.github.io/meetings/2017-09-12/audio.ogg

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: https://goo.gl/WVHuDh
Joe Andrieu is scribing.
Scribe on
Christopher Allen: https://github.com/w3c-ccg/did-spec/issues/21
Christopher Allen: 
  https://www.eventbrite.com/e/rebootingweboftrust-design-workshop-v-fall-2017-in-boston-area-usa-tickets-34984665075
Christopher Allen: 
  https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/tree/master/topics-and-advance-readings
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: https://github.com/w3c-ccg/did-spec/issues/21
Christopher Allen:  Next on Agenda. Issue 21

Topic: Proofs vs. Signatures 

  ... Manu has summarized which bugs should be first on our 
  triage
Christopher Allen: https://github.com/w3c-ccg/did-spec/issues/15
  ... #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

Christopher Allen: https://github.com/w3c-ccg/did-spec/issues/11
  ... 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: 
  https://github.com/w3c-ccg/did-spec/issues/15#issuecomment-328907981
  ... but we should probably restructure that. Thoughts, Manu?
Christopher Allen: https://github.com/w3c-ccg/did-spec/issues/10
Christopher Allen: https://github.com/w3c-ccg/did-spec/issues/4
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: 
  https://github.com/w3c-ccg/didm-veres-one/issues/1#issuecomment-328880658
  ... 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.
Manu Sporny: https://github.com/w3c-ccg/didm-veres-one/issues/1
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.
Manu Sporny: Original DID implementation: 
  https://demo.authorization.io/dids/did:8743453f-e45e-4ac6-b85f-4513ba4c1460
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 
  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

Received on Tuesday, 12 September 2017 19:26:57 UTC