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

Thanks to Susan Bradford and Christian Lundkvist for scribing this week! The minutes
for this week's Credentials CG telecon are now available:


Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

Credentials CG - DID Hardening Task Force Minutes for 2017-12-14

  1. Current Status of DID Hardening Discussions
  2. Options for Keys / Authentication
  3. Option #D
  1. Eliminate Option #3 from the discussion choices as described 
    in this email: 
  Drummond Reed
  Susan Bradford and Christian Lundkvist
  Drummond Reed, Susan Bradford, Nathan George, Markus Sabadello, 
  Mike Lodder, Christian Lundkvist, Sam Smith, Brent Zundel, Kim 
  Hamilton Duffy, Adrian Gropper, Manu Sporny, Dave Longley, 
  Christopher Allen

Susan Bradford is scribing.

Topic: Current Status of DID Hardening Discussions

Drummond Reed:  Any conclusions or options that came out of the 
  worldview conflicts email thread?
Adrian Gropper: The worldview dichotomy appears as we try to 
  standardize the way scopes are handled. OAuth and UMA on top of 
  OAuth seem to have an allergy to linked data protocols (I don't 
  understand why). Meanwhile linked data could be a solution to 
  making scopes clear and reliable in UMA (but I have no experience 
  with RDF).
Manu Sporny:  Suggests that we not dwell today on the 
  philosophical level. How does it look IN the did doc?
Christopher Allen: Just arrived.

Topic: Options for Keys / Authentication

Drummond Reed:  Manu has done a good job of framing the options. 
  We will go through the shared doc and drummond will make notes
Drummond Reed:  Options are here - 
Christopher Allen:  Scared about some of these approaches comes 
  from SSL. Everything was adaptable. it made it very difficult. 
  Created cypher suites. Could be added onto, etc. Ended up having 
  several hundred cypher suites. Desire to keep it standard in a 
  high lever spec that everyone supoorts scares him. BTCR - there 
  are a bunch of things we cannot easily support.
Sam Smith: @Chris if both algorithmic agility and cypher suites 
  are bad what is your proposed solution
Christian Lundkvist:  Wants to speak on option 3. Believes it 
  goes against what DID docs are supposed to do.
Drummond Reed: +1 To Christian's point that "if nothing about key 
  management and description is standardized, we won't have 
Manu Sporny: +1 To that as well... we're trying to standardize 
  stuff here... 
Manu Sporny: Specifically, at least authentication mechanisms and 
  how you express them.
Christian Lundkvist:  Any method could support whatever cypher 
  suites that makes sense to them. Provide a list of standards that 
  can be used.
Manu Sporny: So, -1 to Option #3
Drummond Reed: +1 To having a list of standard cryptosuites to 
  choose from - that's been the proposal for standardized key 
  descriptions all along.
Drummond Reed: Yes, -1 to Option #3
Kim Hamilton Duffy:  Options A,B,C. It can be confusing to 
  implementers if the elements are expressed component wise. Of the 
  three options, B would be a non-option. Does not cluster
Kim Hamilton Duffy:  Her preference would be closer to Option A. 
  Wants to understand more about implosionist suites.
Drummond Reed:  Thought a firm decision was made that the access 
  rules for updating the did doc are method specific.
  ... For methods that want to describe those capabilities, we 
  should do a different spec.
Drummond Reed:  Agrees that key management service description 
  are in scope and have been all along.
Drummond Reed:  Scope questions broader than key management has 
  come up.
Drummond Reed:  How to express the overall model for key 
  management - keeps hearing there are certain combinations that 
  are best practices. Put all the umph behind that. Need to 
  encourage best practices.
Nathan George: +1 To both ledgers and applications leveraging 
  keys in a DID document AND having some interoperability scope to 
  those keys (to keep things functionally compatible)
Manu Sporny:  Is there an option that was not expressed in his 
Drummond Reed: +1 To Dave's point that DID docs need to be able 
  to express two categories of key material: 1) keys or proofs 
  necessary to update the DID doc, 2) keys or proofs needed by 
  various applications.
Manu Sporny:  Can we eliminate any of the options now?
Drummond Reed: Totally agree that we want to standardize any 
  common functionality across ledgers, including any usage of keys 
  that needs to work across ledgers.
Manu Sporny:  -1 To not standardizing. Wants to hear what Sam's 
  thoughts are on Option 3. WHere do we go from there? We may be 
  able to reifne the problem set of what we are trying to solve.
Sam Smith:  Option 3 is not what is what he is proposing. He was 
  proposing where almost everything is in the key type.
Drummond Reed: Sam explained that what he thinks should be bound 
  is the cryptographic suite, operation, and version.
Dave Longley: +1 To what Sam is saying about key type -- it's 
  what we do with Linked Data Signature suites
Dave Longley: (Which includes a "year" as a version)
Manu Sporny: +1 To what Sam is saying -- which is exactly what 
  Linked Data Signatures do via SignatureSuites.
Drummond Reed: Wondering if we can get a subset of this group to 
  agree on a "best practice for key descriptions" and then 
  recommend that back to the group?
Sam Smith:  If you want cryptography that progresses in time, you 
  have to have a way to have the hooks for management. Ability to 
  revoke, and maintain.
Dave Longley: Putting the year in the suite also is a strong 
  indicator of version vs just "version 1" or "version 2"
Christian Lundkvist is scribing.
Drummond Reed: Thanks Christian.
Nathan George: Chairs: at some point should we close the queue so 
  that we can propose to eliminate options or make some type of 
Sam Smith:  The purpose would not be in the type, you can use a 
  signing key for authentication or other things
Drummond Reed: @Nage yes, but I don't know the procedure for 
  that. Can you suggest it?
Christopher Allen:  General problem - there may be a problem with 
  combinatorial complexity when doing cipher suites as well
Kim Hamilton Duffy: My confusion is cleared up: Sam clarified 
  that purpose isn't in the type, which is consistent with LD 
Drummond Reed: Ok
Christopher Allen:  What do we need to define in order to do CRUD 
  operations on the DID document?
Drummond Reed: The problem is that I'm not sure we've reached 
  that point in the discussion.
Christopher Allen:  We might be trying to do too much
Dave Longley: And "application" or "application class" shouldn't 
  be in the type either, IMO. -- but we need to capture that in a 
Kim Hamilton Duffy: I'd like to understand the differences 
  between option B and C; can someone speak to that more
Kim Hamilton Duffy: ?
Sam Smith: Key material is in the key bag for the universal 
  purpose of key management that is discovery to enable suite 
  upgrades rotation revocation.  The specific purpose is in a 
  different branch than the bag with a reference to the key 
  material in the bag. This is now a graph not a tree
Drummond Reed:  Everyone in favor of having the ability to do 
  CRUD on DID document. Option #3 might be enough to support that, 
  but this kicks interop key mgmt down the road (needed for 
Sam Smith: Specific purpose is authentication, etc etc
Drummond Reed:  My reaction to #3 is "lets' not say CRUD on DID 
  docs is the only thing we'll do"
Drummond Reed:  Evernym has contract with DHS to do key mgmt part 
  - so it's important
Manu Sporny:  Can we have a vote to eliminate option #3 from the 
  list of key descriptions?

PROPOSAL:  Eliminate Option #3 from the discussion choices as 
  described in this email

Nathan George: +1
Dave Longley: +1
Kim Hamilton Duffy: +1
Mike Lodder: +1
Drummond Reed: +1
Christian Lundkvist: +1
Sam Smith: +1
Manu Sporny: +1
Christopher Allen: +0

RESOLUTION: Eliminate Option #3 from the discussion choices as 
  described in this email: 

Manu Sporny:  Kim pointed out differences between #3 and #C
Manu Sporny: 
Manu Sporny:  ChristopherA says need to be careful about algo 
  agility, Sam agrees in general
Manu Sporny:  We have suites in JSON-LD, need to cut down the 
  suites to a small amount that makes sense
Sam Smith: Jose bad yes too much agility
  ... JOSE/JWT stack has issues with algo agility, very loose wrt 
Manu Sporny:  If you like restricted algo agility suites JOSE 
  might not be a good choice
Manu Sporny:  Sam + evernym folks like #A a lot
Sam Smith: But JWT is good not for algo agility but because 
  signatures are not embedded in graph
Drummond Reed: +1 To Manu's point that we want to be very 
  specific about what a key can be used for.
Manu Sporny:  Folks seem to be against total combinatorial 
  agility, which is good
Manu Sporny:  In option B we break out what a key can be used for
Christopher Allen: Can application and purpose be one value?
Kim Hamilton Duffy: I thought Sam was supporting something closer 
  to option C, but he's on the queue and can speak to that
Kim Hamilton Duffy: I.e. separating out purpose
Dave Longley: I would think so (application and purpose captured 
  in one value ... or even application "class" to allow multiple 
  applications to use it)
Christopher Allen: Thus type: signaturesuite apppur: 
Manu Sporny:  In #C you encode the application of the key through 
  the relation.
Sam Smith: I am proposing an option D
Dave Longley: In option C the relation could include purpose and 
  application/application class.
Manu Sporny:  In #B the application lives with the key
Sam Smith: Option D is option C is expressed as a compact string 
  plus a version which is not in C.  and then Purpose is in its own 
Dave Longley: "Purpose" is also not fully pinned down, IMO -- 
  whether we're talking about crypto operation only or something 
  higher level... which is why things like "authentication" as a 
  purpose is a bad idea, IMO. ... that's not a crypto operation, 
  it's an application level consideration
Drummond Reed:  Have a lot of regard for crypto-folks in this 
  group. Those who have the battle scars and care about this, if 
  those ppl came together and come to consensus that I would 
  probably support it.
Dave Longley: It should be done as a relation only ... you can 
  use this key to authenticate that this entity, for example, 
  signed something.
Sam Smith:  I propose "option D"
Drummond Reed:  Should we propose that a subset of ppl hammer out 
  a proposal and bring it to the group?
Christopher Allen: The date is a version
Christopher Allen: RSACryptographicSigningKey2017a

Topic: Option #D

Sam Smith:  Option D above: Take #C, add a version, combine it 
  into a small type string
Dave Longley: I like OptionD *minus* the key encoding. (Sam 
  didn't mention encoding)
Sam Smith:  Values are a tuple, not optional
Drummond Reed: I'm also intrigued by Sam's Option D proposal
Sam Smith:  Application purpose exists somewhere else in the 
Dave Longley: OptionD ... RsaCryptographicSigningKey2017 ... and 
  then "publicKeyPem" contains the key material in PEM format 
  (other terms can specify it in other formats)
Kim Hamilton Duffy: Me too, but also wondering about status of 
  encoding in this world
Sam Smith:  Somewhere else is specified the ontology etc, we 
  decide if we want to standardize some of that
Christopher Allen:  One of things that drew me in to this 
  community was the signature suite date that specified the version
Christopher Allen:  Willing to concede that same signature/proof 
  system could have application + purpose
Christopher Allen:  Can see specific crypto methods supporting 
  signing and not encryption etc
Drummond Reed: Interesting point ChristopherA brings up about 
  "signcrypt" keys
Sam Smith: @ Manu  not signature suites but cryptographic suites  
  at a given level of cryptographic strength
Christopher Allen:  If I can be persuaded there is a concise list 
  of application + purpose then I'm willing to accept that. Not 
  sure I like the idea of separating application + purpose into two 
Christopher Allen: I still lean to proofs.
Manu Sporny:  I find Sam's option #d intriguing. If Sam can type 
  it up would be good
Manu Sporny:  Pros/Cons:
Dave Longley: It requires every new application to maintain an 
  ontology for key types
Drummond Reed: +1 For Option A including a year (for versioning) 
  and it makes it easier for developers to exactly specify a key.
Manu Sporny:  #A Pro: Very specific, can't get more specific. 
  Almost impossible for devs to screw up. Cons: May be in a 
  combinatorial problem. May be 50-100 types springing into 
Manu Sporny:  Option #A could turn into bad combinatorial problem
Manu Sporny:  #B Pro: No combinatorial problem. Con: Developers 
  can easily screw it up if they only pay attention to some parts
Dave Longley: Imo, key purpose, where that refers to permitted 
  crypto operation only, should always be baked into the key type.
Dave Longley: Application/application class/other kinds of 
  higher-level "usage" should be done via a relation (DID subject - 
  relation - key)
  ... #C Attempts middle ground: No need to do purpose in the 
  type. Don't open the misimplementation problem as badly.
Drummond Reed: Drummond wonders whether we should have a poll to 
  see if we can eliminate Option B?
Manu Sporny:  Looks like we're going back to signature suites and 
  saying they're a good idea. The sig suites right now are put on 
  "proofs" and not
Manu Sporny:  Looks like we're going back to signature suites and 
  saying they're a good idea. The sig suites right now are put on 
  "proofs" and not "key material"
Manu Sporny:  In suite we are binding the key type, application 
  and purpose together. It's more of an application suite
Dave Longley: +1
Sam Smith:  I just posted an email in the "worldview" email 
Dave Longley: Binding of application or "higher-level use" should 
  be done through relation, IMO.
Sam Smith:  Strong agreement with almost everything Manu said. 
  Don't think everything should be in type. Everything except 
  purpose should be in type. also version
Drummond Reed: +1 To Sam's point that version belongs in the key 
  type description.
Sam Smith:  Then we break discussion of key managment/material 
  away from the usage
Sam Smith:  Everyone wants their worldview to be a MUST. Not 
  always possible, can use SHOULD
Dave Longley: +1 Yay for Sam.
Sam Smith:  Limit the MUST to the simplest, most universal things 
  we can agree on. Other stuff can be SHOULD
Sam Smith:  Signing is a crypto operation inside a crypto suite
Drummond Reed: +1 To our job here being to describe key material 
  within a cryptographic suite
Sam Smith:  Every operation is tied to the same suite
Sam Smith:  Bigger than signature suites - we're talking about 
  cryptographic suites
Drummond Reed: +1 To specifying cryptographic suites
Sam Smith:  Signing, MACs etc all from the same suite
Sam Smith:  Suggests key bag with crypto suites, then application 
  specification elsewhere in the graph
Dave Longley: *And* we should make sure that we don't let the 
  *meaning* of that signature bleed into that suite, that's 
  application layer stuff... for example, does a signature mean 
  "someone made a claim about me (verifiable credential)" or does a 
  signature mean "sign me into this service" ... both of these are 
  "authentication" -- but it's up to the application to decide what 
  that means.
Sam Smith:  Type should be "cryptographic suite, operation, and 
  version". The value is the actual key itself, and the id is a 
  unique way to reference that key. [scribe assist by Drummond 
Kim Hamilton Duffy: Option D is very promising to me. 
  Cryptographic suites make sense as an entity on their own. The 
  final type "blesses" a valid combination (along with a version)
Drummond Reed:  Is there enough interest in option #D that we 
  should write it up?
Kim Hamilton Duffy: +1
Mike Lodder: +1 Option D
Drummond Reed:  Other proposal is to have a subgroup to think 
  about it and come back with a proposal
Sam Smith: @ChristopherA  as long as its a tightly bound tuple or 
  string its that same to me
Mike Lodder: +1 Examples
Sam Smith:  Option D is written up in an email.
Drummond Reed:  There are no examples yet
Christopher Allen: I'd really like to see a start list from Manu 
  of applicationpurpose are already implied by current 
Drummond Reed: Drummond notes that keyref is also something 
  that's needed in service descriptions
Manu Sporny:  A bit concerned about key ref in option D. Still 
  assumes we have a bag of key material
Sam Smith:  For key mgmt the bag allows us to do key discovery.
Drummond Reed: Drummond notes that this question - about having a 
  "bag of keys" - is one of those worldview conflict areas.
Manu Sporny:  Huge discussion to have there. Want to focus now on 
  the stuff we're almost there on
Manu Sporny:  The "type" specifier doesn't have to be a long 
  string with combinatorial issue
Christopher Allen: The name of a cryptosuiteV doesn't constrain 
  it — it is the spec that is behind that name of suite points to.
Manu Sporny:  We should go out and specify all the suites there 
  are and see how many there are
Manu Sporny:  Type should be crypto suite or application suite, 
  need to see JSON or JSON-LD markup to see if we're on same page
Manu Sporny:  Others can weigh in on key material
Dave Longley:  Need to be careful with "value" since more than 
  one format to represent a key
Dave Longley:  In general think it's a good approach
Drummond Reed: Dave points out that there's more than one format 
  for serializing a key, so the encoding is also part of what needs 
  to be described.
Dave Longley: That sounds like microformats which i'm -1 to
Christopher Allen:  Not that concerned about value. Could be up 
  to the app/crypto suite to support the value format
Dave Longley: I'm fine with the appsuite defining what to do, but 
  they wouldn't use "value" (i wouldn't think).
Christopher Allen:  Really would like to have an idea of the 
  application purpose - how many of them are there? How many can 
  support the values we would be using? Both for the CRUD of DID 
  docs and also for verifiable claims
Dave Longley: I'm interested in what nathan has to say about 
  application vs. key-intent ... i think we're conflating things a 
  bit and i'm not sure where everyone is.
Mike Lodder:  Sounds like we don't want to do Option #A or option 
  #B? Should we take those off the list?
Nathan George:  Application suite implies that we know in advance 
  what the applications are, and that might not be the case
Dave Longley: +1 To nathan, "application" is an ambiguous term i 
  think, in this discussion.
Dave Longley: And application in the way nathan means -- should 
  be defined by relation (or an application class should be defined 
  by relation), it isn't part of the key type.
Drummond Reed: Nathan said that its not so much application suite 
  - because that's not a fixed list - developers can "use or abuse" 
  any key for anything they want. So intent of usage is imporant.
Dave Longley: But that's separate from "key intent", etc.
Nathan George:  Don't think we have the ability to enforce the 
  usage of keys for specific applications
Mike Lodder: +1 Drummond for key specs and intent
Dave Longley:  The Crypto suite defines the crypto guarantees, 
  but I think we are trying to express is some additional 
  "recommended criteria for selecting this key for your use-case" 
  [scribe assist by Nathan George]
Drummond Reed:  Let's use the mailing list as much as we can.
Nathan George:  Which is fine by me -- i just don't want 
  extremely specific applications to bleed into the key type. 
  [scribe assist by Dave Longley]
Drummond Reed:  We still need to discuss service descriptions and 
  Sam's HD metadata stuff
Dave Longley: YahooSignInKey
Christopher Allen: Gotta run. Ciao!
Dave Longley:  We're on the same page there, and when someone 
  says "applicationsuite" I'm afraid of types like 
  "PlatformX_DoItExactkyMyWayForAuthentication" types [scribe 
  assist by Nathan George]
Dave Longley: Yup
Dave Longley: -1 To that.

Received on Thursday, 14 December 2017 20:00:09 UTC