- From: <msporny@digitalbazaar.com>
- Date: Fri, 05 Jan 2018 12:55:55 -0500
- To: Credentials CG <public-credentials@w3.org>
Thanks to Susan Bradford for scribing this week! The minutes for this week's Credentials CG telecon are now available: https://w3c-ccg.github.io/meetings/2017-12-21/ Full text of the discussion follows for W3C archival purposes. Audio from the meeting is available as well (link provided below). ---------------------------------------------------------------- DID Task Force Minutes for 2017-12-21 Agenda: https://lists.w3.org/Archives/Public/public-credentials/2017Dec/0080.html Topics: 1. Cryptographic Key Material Organizer: Christopher Allen and Kim Hamilton Duffy and Joe Andrieu Scribe: Susan Bradford Present: Susan Bradford, Drummond Reed, Dave Longley, Sam Smith, Christian Lundkvist, Mike Lodder, Adrian Gropper, Chris Webber, Brent Zundel, Markus Sabadello, Daniel Buchner, Manu Sporny, Nate Otto, John Jordan, Christopher Allen Audio: https://w3c-ccg.github.io/meetings/2017-12-21/audio.ogg Susan Bradford is scribing. Drummond Reed: Discussion of cryptographic key material Topic: Cryptographic Key Material Drummond Reed: 2 Proposals to go through Drummond Reed: #1 Single flat array of key description objects Drummond Reed: These are examples of types. Work has not been completed on algorithm for things in the name yet. ... Added cryptographic version and key Drummond Reed: Advantages: Simplicity, one-step selection, promotion of crypto best practices ... Disadvantages: not RDF friendly ... Variations: coding should be a separate field. ... Possible mitigations: key material can be in a graph instead of a tree. Still have an RDF friendly path Dave Longley: We may get into the same best of both worlds in both proposals. May be able to merge the two Drummond Reed: +1 That key material should be described in a way that is independent of the DID method. Dave Longley: Allows it to list keys that may not be owned by the DID owner. Dave Longley: Calls out who is the key owner Dave Longley: Want to see the relations: who is this keys ownher Dave Longley: Key encodings are separate from the key type. Dave Longley: Listede a biometric template that is not strictly a key Dave Longley: Ability to effectively present proofs and some auth material that proves you are the only to establish that proof. Dave Longley: Version base off a year. Dave Longley: Advantages: Simplicity, one-step selecti0on, promotion of cryptographic best practices, year based versions, friendly for JSON-LD, RDF and regular JSON, signular names for properties, flexibility and extensibility Drummond Reed: +1 To using singular names for properties. I've been equivocating about that for years. Dave Longley: Disadvantages: morethan one place to find a key, increase complexity, lack of use cases beyond "authentication" and "key management" Dave Longley: "You only need to care about the relations that matter to you." [scribe assist by Drummond Reed] Dave Longley: Longley: would be nice to see use cases Sam Smith: Concern that all keys are subject to key management. Sam Smith: "All keys are subject to key management, not just those listed in keyManagement" [scribe assist by Drummond Reed] Sam Smith: "I think we need to be enable key management as a first-order property of any DID document". [scribe assist by Drummond Reed] Sam Smith: If the bag of keys is for key management, then they are doing it wrong Dave Longley: Key management being separate area is one variation of this proposal that he would be ok with. Dave Longley: No duplicates when looking at this as a graph model Dave Longley: Having key management be a separate application is something he's open to. [scribe assist by Drummond Reed] Sam Smith: Concern that it will be hard for naive JSON-LD users. Dave Longley: You may be listing keys that are not owned by you. Chris Webber: 1St section: ambient auth problem. Security risk if you put everything in the same bucket. Chris Webber: Shouldnt be mixing the purpose in the type Chris Webber: 1St proposal would be better if we had "purpose" Dave Longley: Yeah -- purpose vs. operation a common point of confusion. Christian Lundkvist: Lack of use cases in proposal 2. Glaring lack of signing of verifiable claims Drummond Reed: For reference, the Google doc we are referencing is https://docs.google.com/document/d/13fp7V3v1nBuhxTI55Al8KLG2kyxFthBz-Ush-ZL58KA/edit# Christian Lundkvist: Concern that this feels like this is a free for all. Christian Lundkvist: Should have some standardizations of terms, otherwise it could be problematic Christian Lundkvist: If everyone can come up with their own relations to describe key material, we could end up with a very long and scattered list of options that hurts interop. [scribe assist by Drummond Reed] Sam Smith: Responding to ChrisW. There is a semantic ambiguity. There is cryptographic application and application purpose. Sam Smith: Use the term "operation" because it is ambiguous. Sam Smith: Cryptographic operatons are different than "purpose". The same cryptographic operation can be used for multiple purposes. [scribe assist by Drummond Reed] Sam Smith: Either put everything in the type, or only break out operation and/or encoding. "Purpose" should be a different type of relation. [scribe assist by Drummond Reed] Chris Webber: Well string splitting / parsing the type string, for one thing (aside from being incompatible with json-ld) is already a messy thing Sam Smith: We have key material that includes a type, not a purpose. Use the path to define the application purpose. Sam Smith: So purpose is something that could be broken out into a relation. [scribe assist by Drummond Reed] Markus Sabadello: To merge the two proposals, could we have a branch to the graph with descriptions Markus Sabadello: Should be able to work with people who only know JSON Sam Smith: +1 Dave Longley: All three of his comments are related to applying the Open World Assumption to DID documents. Which in this context means that each application can specify the relations that it needs. [scribe assist by Drummond Reed] Drummond Reed: Sorry cwebber: couldn't tell who it was. Manu has joined Mike Lodder: I'm not sure why you need an owner field when owning a key could serve the same purpose Christian Lundkvist: Pragmatically if a dev wants to develop against the did doc, and we only specify _________________end up putting everything in one bucket\ Christian Lundkvist: Developers will choose the path of least resistance Christian Lundkvist: Worries that if any purpose can contain an array of keys, then developers won't actually know where to put a key, because they can all interpret purposes differently. [scribe assist by Drummond Reed] Manu Sporny: Putting every key in "authentication" would be an abuse of that property. [scribe assist by Drummond Reed] Manu Sporny: Call out that certain fields are used for certain things Mike Lodder: The problem is if there are too many options developers have to do lots of homework to use it Manu Sporny: Break these out into application classes, may need to narrow them Christopher Allen: (Synonyms: certification verification attestation corroboration evidence proof substantiation testament testimonial) Christian Lundkvist: That was not really my argument :) Christopher Allen: +1 To more narrow Chris Webber: +1 On getting consensus that the application distinction is important as the next step Chris Webber: It sounds like we're very close to all ack'ing that Chris Webber: (Regardless of the approach taken) Sam Smith: If i were i naive programmer coming to this spec and was told that if you wanted your key to be managed, in the appropriate dumping ground. If they dump it in key management, at least its manageable. Sam Smith: If you want it to be interoperable, use a narrow defined application purpose Sam Smith: Having application purposes that are narrow is a good thing as long as we don't lose the other half of the application Drummond Reed: Agrees with Sam. Have one place to manage keys, volunteered to make a proposal that merges those Drummond Reed: @Dlongley: yes, I think you are right Christian Lundkvist: If you have narrow application purposes and you want to enforce it, that necessitates a lot of coordination. Christian Lundkvist: Concern devs wil make up their own, and they won't be compatible. Or dump them into the wrong purpose Dave Longley: We could tell them that they need to use JSON-LD to properly use relations if that's an issue for those developers :)... you don't get those conflicts. Drummond Reed: To summarize what I said, a proposal that combines a flat array of keys for the purpose of "direct reference" and key management with using RDF relations to describe the purpose of any of those keys will give us the best of both worlds. Christian Lundkvist: The 2nd proposal will become more like the 1st proposal due to the fact you have to come up with different application purposes Dave Longley: I don't buy the argument that if someone is inaccurate that everyone will be John Jordan: From a naive person's perspective it sounds like the challenge is to create conditions where this is sufficient specificity to set us off in the right direction to allow network effects to take hold on the semantic meaning of these elements Drummond Reed: Well said, John_Jordan Sam Smith: What we can do to address the concern, be explicit in the must vs should. Sam Smith: Only if the devs really know, then they can put it in an application purpose. Sam Smith: Recommends that we say that adding a key reference to an application purpose, it should be a SHOULD. [scribe assist by Drummond Reed] Mike Lodder: I agree with Sam. Thats calms my fears Drummond Reed: +1 To what samsmith just said: that the spec should say a key MUST go into keyManagement but that if a developer needs to express an application purpose, they SHOULD list the key under a relation. Drummond Reed: Drummond disagrees with Manu's contention that "creating a generalized container is a bad idea". Manu Sporny: Compromise: creating any kind of generalized container is a bad idea. the reason you create standards is to prevent interoperability. Drummond Reed: The reason is that the "generalized container" is a very specific type of data structure for a very specific and important purpose: key management. And most importantly, that the type field in key descriptions in this array carries the essential description information that developers need to choose the right key. Manu Sporny: If a dev makes a mistake and puts it in the wrong place, they can always correct it Sam Smith: In a naive JSON DID the bag of keys is there for the purpose of key discovery. Dave Longley: I think it's a bad idea if you don't have *any* other relations Sam Smith: The reason people want the key bag is so its easy to do the right thing. Sam Smith: Manu, it gives the naive JSON developers easy to do the simplest thing. Manu responded that developers can just search the entire document for keys. [scribe assist by Drummond Reed] Dave Longley: If you only use "keys" as a place to find descriptions and other fields are where you *start* to find the key for the right purpose ... you're ok (that includes key management) ... if we have nformative material, most devs will respond to that. if we force them to do it without clear guidelines. that is why we need the "should" Sam Smith: If we educate developers about why and how to use application relations to describe a key is a "good SHOULD". [scribe assist by Drummond Reed] Time check: 10 minutes Christian Lundkvist: Question on key management application purpose. unclear what that means exactly. are they the keys that allow an update to the DID doc? It seems method specific to have those. Christian Lundkvist: Seems like key management might live somewhere else. potentially in the method specs. Sam Smith: Christian keys that are managed not keys that are used for managment Christian Lundkvist: Seems more related to the discovery Drummond Reed: Reminder to myself to state what I think the benefits of the "middle ground" proposal are: use an array of keys (best name for that array TBD) to list all keys, and use relations to describe the purpose of those keys. Dave Longley: I just wanted to say that not ALL keys may need key management, especially those not owned by you. Markus Sabadello: One assumption we make is that we have complete freedom to add to the did doc. That is hopefully what the did methods support. but there may be methods that don't. Dave Longley: Then those other DID methods won't work with many applications :) Christian Lundkvist: Still a bit confused, was the "keyManagement" list one that contains all the keys? It would mimic the "keys" bag of Proposal 1? So "keyManagement" is not really a application purpose but more of a collection of the keys? Christian Lundkvist: I should say all the keys owned by the users Dave Longley: No way to specify services or anything else sounds like a fairly useless DID :) Drummond Reed: Quick poll to see, of those on IRC right now, who is in favor of the idea of creating a joint proposal based on what Drummond just summarized. Pleaes +1 or -1 for the minutes. Drummond Reed: +1 Drummond Reed: Manusporny: proposes a simple library call to do getAllKeys. He does not agree with the "bag of keys" approach. Sam Smith: But then the application purpose becomes a MUST not a SHOULD Drummond Reed: +1 To Sam's point. Drummond Reed: -1 GetAllKeys Sam Smith: -1 GetAllKeys Drummond Reed: This is where we get to the "conflict of worldviews" issue that I emailed the list about. Markus Sabadello: Some minimalistic DID methods may not support specifying a purpose for a key. Drummond Reed: +1 To Markus' point Sam Smith: +1 Drummond Reed: Talk about next steps... Drummond Reed: Volunteered to start a third proposal. Chris Webber: Note that json-ld *is* an attempt to find that intersection Chris Webber: Between naive json and graph-land Chris Webber: We've talked about making sure we can uphold both at once Chris Webber: I think we still can :)
Received on Friday, 5 January 2018 17:56:47 UTC