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. ✪

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 - https://lists.w3.org/Archives/Public/public-credentials/2017Dec/0046.html ✪

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 interop" ✪

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. ✪

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 email? ✪

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" ✪

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 decision? ✪

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 signatures. ✪

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 relation. ✪

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 applications) ✪

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? ✪

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 ✪

Manu Sporny: Kim pointed out differences between #3 and #C ✪

Manu Sporny: https://w3c-dvcg.github.io/ld-signatures/#signature-suites ✪

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 ✪

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: vcissuersigning ✪

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 branch ✪

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 ✪

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 bag/graph ✪

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 fields ✪

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 existence ✪

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) ✪

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 thread ✪

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 Reed] ✪

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 implementations ✪

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. ✪