DID WG 6 Nov 2019 Key representations Ad-hoc meeting — Minutes

Date: 2019-11-06

See also the Agenda and the IRC Log

Attendees

Present: Michael Jones, Brent Zundel, Markus Sabadello, Dave Longley, David Lehn, oliver terbu, yancy ribbens, Daniel Burnett, Orie Steele, Amy Guy, Manu Sporny, Dmitri Zagidulin, Ganesh Annan

Regrets:

Guests:

Chair:

Scribe(s): Brent Zundel, Amy Guy

Content:

Manu Sporny: burn: This is a discussion meeting, we don’t want final decision made on this meeting, want to bring it back to the main group.

Manu Sporny: brief overview is that we are talking about whether to use jwk or to support multiple formats
… we all agree I think that too many would be not good
… success for the call would be a rough sketch of what could go in the spec

Oliver Terbu: what is the current status to support non-public key methods?
… option one is keep the current ethereumAddress
… option two is to use a common format to encode an ethereum address
… option three: don’t add ethereumAddress at all

Orie Steele: +1 for authentication section for non public key material in did doc

Dave Longley: +1

Orie Steele: I’m glad oliver brought up ethereum address, I’m eager to gather consensus around it
… my preference would be for that to be in the authentication section directly, and prefer not to have ethereum address or bitcoin address stuff be defeined in the jsonld context.
… if we go down that route we should be prepared to make lots of changes to the did context to support everything new
… Since DID documents assume json encoding it would be a really big shame if we didnt’ support the best key encoding format for json which is jwk
… with that comes a lot of support for legacy systems
… I’m in favour of mandatory support for jwk and if I had to pick another key format that had mandatory support the next would be pem
… I think there’s probably a reasonable arguemetn to be made for a couple
… More than a couple is really not that good
… jwk that’s my primary desired key format. If I had to have others supported, at least pem as well

Michael Jones: a bunch of stuff I’m gonna respond to
… manu produced a summary of some of the discussions in the last call
… I’d like to add that if we decide that we will allow multiple key formats for a particular public key type, which I’m not conceding
… the point I made before was if we do that we enumerate them now
… for known key types, and do not allow any more
… for example, for rsa keys we should have proably jwk
… and at most one other format, maybe pem
… but we put those in our document, not in a separate registry, and we say this set will not be extended
… likewise for elliptic curve keys we would say that jwk support is mandatory and at most one other format
… i think the at most one other is a standards failure, but manu’s description didn’t include the statement that we will never add new formats
… there’s a distinction
… New key types and new authentication methods will show up
… I’m not trying to limit extensibility when there’s actually innovation
… But where we already know the key representations in terms of how many bits they take
… We should choose and we should choose now
… Next point responding ot things that have been said - I think the scope of our discussion is to talk about representation of public key types
… I concede that in DIDs there will be many other things
… that are not necessairly public keys
… I don’t want us to try to determine representations for them on this call
… One thing that came up was the discussion about ethereum address, which is a active issue
… it came out on that thread that that’s not a public key
… it’s cryptographically derived from a public key
… So I think given an ethereum address i snot a public key discussing it is out of scope for this call
… The point made by the earlier speaker that we have a json encoding we should use a json representation as the primary representation.

Dave Longley: I agree with some of the things mike was saying
… we have this abstraction of verification methods that tends to encapsulate public keys and other things
… we’ve put work in making sure you can identify them by their id, and generally also a type
… a number of things in the DID resolution spec and ongoing work about referencing them by fragment ids etc
… a verification method can be a public key but it can be something else like an ethereum address
… ew don’t need the details in how to represent an ethereum address
… but it’s imortant that we have verification methods that have an id or type, and some other properties
… that encaspulate key material
… eg. publicKeyJWK or publicKeyPem
… and use the formats under that property
… we can discuss any of the multibase things might be used
… but what we do end up discussing we should write down for the types of keys that exist today this is how you can express them in a did document
… then make it clear if there are new things, it’s extensible
… but if you’re using an existing public key format, you should use one from the spec

Markus Sabadello: I was wondering if we’d have one that enumerates the public key formats that would allow to all the public key types, or if that would be specific to individual public key types
… feels like some formats are applicable to multiple key types and extensible and can be expected to be adapted to future key types
… that includes jwk and maybe also the multibase
… those could be used to express many different key types
… but then there are formats that feel popular for only one or two specific key types
… pem is for rsa, for ed25519 people prefer base58
… I wonder if we would enumerate the allowed formats specific to the key types, or just have one list

Manu Sporny: I think dave already mentioned.. oliver and orie raised the ethereum address thing and yes, we have a mechanism today in the spec that lets you express that. They are a valid verificaiton method
… verification methods can go in the authentication field
… we have a clean solution to that
… We dont’ have details on how you’d express that but I feel pretty good we’re headed in the right direction
… we support them today
… orie mentioned that we have a json format for a DID document
… i don’t know if we should make that assumption. We have a data model for DID documents
… we expect that most people will express it using json, but like with VC it’s dangerous to assume that the standard format is always going to be json
… We could easily see implementations encoding it in CBOR and if they do that the JWK format doens’t make as much sense
… but that’s certainly not an arguement against jwk. We should support jwk across the board
… The only thing I think we’re modulating that with is saying for RSA a lot of the existing libraries expect and consume pem encoded data. that’s why it’s okay if you’re expressing an RSA key to express it using pem encoding
… like markus said, for ed25519 a lot of implementations seem to be doing binary, simpler encoding format
… So I think at some point in this call we should talk about RSA because that’s the easiest one to come to some kind of consensus on
… The other uncomfortable question was what about COSE key format
… there’s a lot of work going on in web authentiation and the things you get back from these authenticators are cose key formatted things
… if we’re going to start using these 2fa devices for authentication wouldn’t it be easier to store the cose key directly in the DID documents
… so web authn mechanisms can just use that, wouldn’t need to covert between multiple formats
… that’s uncomfortable because eg. for RSA we support jwk and pem and cose keys
… Want to throw that quesiton out, what about these COSE based binary formats

Orie Steele: 3 formats for RSA keys… ;(

Michael Jones: I’m an editor of web authn so I can speak authoritatively about why we used COSE key format
… That was a decision I advocated
… We’re speaking a binary protocol to authenticators over low bandwidth connections such as NFC and bluetooth lo energy
… so it was decided to use a binary format for that
… to not have web authn implementations to have to do format conversions
… There’s no such situation here
… As far as yes we have a data model but the data model sepcification we have represents everything in JSON
… if we wanted to recharter and add a CBOR representation of the data model we could do that but I believe it’s out of scope
… It’s not hard it’s just more work and people would have to do multiformat then
… I’m also going to respond to manu’s comment when he said if we support ? there would be no need to convert from multiple formats
… I think tha’ts false
… For every format you support a general purpose implementation is going to have to convert from that format to whatever it’s native format is for its crypto libraries
… you can guarantee that you’re doing at least n-1 conversions for n formats
… My point is for advocating one, if you support one format it’s guaranteed you’re doing only code for 0 or 1 format conversions
… Every new supported format requires conversion which is extra code and testing and interop problems
… Finally, mentions of a number of one off formats
… which we could go over in turn but I think I’ll pause there
… The multibase thing is an atrocity
… It’s explicitly a choice not to choose
… it requires you to have code for a union of things that could get extended
… please lets not entertain that

Manu Sporny: Mike, I get the arguement that the more types you have the more conversions you have to do from one to the other
… there’s general agreement that that’s typically a bad thing
… The multiple formats concern I think is coming from a standpoint like, say we pick jwk
… and today openssl and those libraries they expect pem encoding
… what you’re going to see with rsa keys in did documents is this mandatory migration from jwk to pem to the format you need for openssl
… the same thing is true for the web authn work
… web authn expects some kind of cose key, you’re going to have to convert from jwk to cose for the web authn mechanism
… if you contrast that with the majority of ssl libraries or rsa libraries, take in pem as a format, and if we eliminated jwk entirely i don’t think the ecosystem for rsa keys would be negatively impacted
… it would be a benefit to the ecosystem because we picked pem and it’s universally pulled into rsa crypto libraries
… I think it’s important to understand, the reason people are saying multiple formats is 1) because we cant’ agree on just one
… and 2) my expectation is (who knows) that for RSA keys if we give an option of pem, the vast majority of implementations are going to choose to do it in pem and not jwk
… I’m wondering if that same thing is true, if the vast majority of applications consuming did documents
… are going to be systems that understand or use webauthn and care about those binary protocols
… I’d expect they’d want to choose the binary encoding of a cose key over something like a jwk
… It’s important to understand that there isn’t one key format we can pick that would b euniversally used in the ecosystem

Dave Longley: +1 pick the format that is most popular for the key type, that reduces conversion the most

Manu Sporny: whatever we end up picking is going to end up needing some kind of conversion to work
… It’s important to understand that people are saying multiple formats because today that’s the reality
… I don’t think we can get everyone to agree on key formats
… We would have to recharter to contemplate a different encoding - I don’t think tha’ts true
… we didn’t do it for VC. yes all the examples are in JSON but we shouldn’t think that prevents the data model from being used in different syntaxes
… like for example CBOR
… I don’t think the group should work on it, but we should keep it in mind
… it can be expressed in things other than JSON

Dave Longley: +1 definitely not true that we need to recharter – data model is syntax agnostic, we’re just providing JSON-LD here in the spec

Manu Sporny: The final thing to do with multibase.. the arguement is not to support every single key format under the sun.
… We saw people say I want to do hex encoding, I want to do base 58, base 64.. one easy way to enable all those different
… they’re different base encodings
… one way to support those base encodings is to use multibase encoded key formats
… we don’t have to support all of them
… for ed25519 we would do really well to use multibase for those to base 58
… if the sec?? folks wanted to encode in hex encoding the exact same encoding format could be used for those

Dave Longley: +1 one standard for the encoding, but limit the number of encodings per key type to most popular

Manu Sporny: rather than fighting over 8 different ways to encode these keys when they only differ in the base encoding, we could use multibase to signal what the base encoding for the key was

Dave Longley: (multibase with restrictions)

Manu Sporny: it would result in less choices
… we could always restrict the specific key formats that we support in multibase

Michael Jones: multibase is a way of enabling people to make the choice of which encoding to use
… instead of the standard making the choice of this is how you represent something
… I’ve built a lot of systems, done a lot of interop work
… the more choices you enable programmers ot make the less interop you have
… people will build the one they think they want
… you will have mostly dusty code paths that may be untested and wrong that when someone else makes a differnet choice you get failures
… the point of having a standard that makes the choices for you is everyone codes to the same code path
… thier implementations may have to do different things but the format is standard and you’re not going to get interop problems
… This is what we’ve already done [in VC].. that’s fine when you’re in an experimentation phase
… but we’re not in an experimentation phase, we’re creating an standard

Dave Longley: Multibase is defacto standardisation at a different level
… it’s about the wrapping for the encoding
… keys are self expressed
… the encoding that they’re in you understand what encoding it is in when the bytes arrive
… it doesn’t mean we would have to support every possible encoding
… it allows us to future proof
… for other keys in the future with a popular base encoding
… it’s not standardising the key representation itself, but it is creating a standard around what base something is in when you look at the data itself
… just at a different layer

Manu Sporny: I want to ask the group, let’s get concrete. Let’s talk about RSA
… All I have heard for RSA are publicKeyJwk and publicKeyPem
… if we were to propose that, would anyone object?
… or want to add one?
… that seems like the easiest win we have
… does anyone here think that for RSA key encoding we should have anything more than publicKeyJwk and publicKeyPem?

Michael Jones: Responding to dave’s comment about multibase. I understand what it is, that you’re letting people choose the base that they’re encoding the thing
… I’m going to apply manu’s earlier argument about pem to multibase
… there is no native librarly support for multibase
… there is native support for providing elliptic curve keys as binary strings
… all of these base encodings end up producing the binary string
… there’s not a compelling reason to allow for multiple encodoings
… we can choose one
… base64url uses fewer bytes than base58 and hex and there’s plenty of support for that
… this is a case where we are better of to choose than to fail to choose
… To manu’s question about jwk and pem
… I wouldn’t advocate supporting any more than that
… As I said, if in some key types we choose to allow more than one so that n=2
… we must say in the spec that n will never grow to 3 for that key type
… I will personally advocate for choosing just JWK which i’m sure is no surprise
… I understand others may feel different
… If we start going down the n extensible route we’re just creating unnecessary interop problems

Brent Zundel: any other responses to manu’s question about RSA?

Yancy Ribbens: I believe there is an acutal difference between an ethereum address and a base58 key encoding that is used by btcr
… if we go down the pem and jwk route wouldn’t that preclude base58 key encodings
… wouldn’t that be a concern?

Manu Sporny: I don’t think that’s what was being propose
… I think for RSA specifically we’re only going to do jwk and pem
… That’s only for RSA keys
… We haven’t talked about sec256k1 keys or ed25519 keys, trying to push those off until later to find common ground
… I havne’t seen anyone say for RSA keys specifically the encoding formats that are supported are jwk and pem and that’s it

Orie Steele: I think for RSA keys publicKeyJwk and publicKeyPem and my preference is basically to have a mandatory MUST support for at least one well defined key format
… From an interop standpoint saying that every valid DID method can support an arbitrary number of optional key formats is not a thing I want to see. There should be at least one MUST support key format in the DID spec
… I’d advocate for JWK but I could become convinced it should be pem
… very unlikely to be convinced it should be anything else

Michael Jones: wrt the most support, if we choose JWK as a must support it will work for all the known key types
… which can’t be said to be true for any of the other options
… there is an argument to be made from an interop perspective that every format that we specify must be required
… otherwise you have different implementatons that can’t talk to each other
… people may react to that with I don’t want to support all those things
… I just want to support one thing
… that’s the point
… if you start advocating for optional key formats you biforcate the world

Markus Sabadello: I don’t have a strong opinion on this. Wondering if a compromise could be to say MUST support JWK because it works for all known key types, as well as future key types
… and we could say in addition we support (for known key types) whatever the most popular format is for that specific key type
… for RSA that would be pem, for ed25519 it would be base58

Manu Sporny: I agree with Mike, we have to say MUST support for all the key types that we’re listing
… for RSA, you MUST support publicKeyJwk and you MUST support publicKeyPem
… support means don’t throw an error
… it doesn’t mean that your DID method has to undersatnd it, but it does mean you have to process it cleanly
… I think I’m hearing consensus around for RSA you MUST support publicKeyJwk and you MUST support publicKeyPem. Would any body object to that text going into the spec?

Michael Jones: I could live with that
… I think it’s unnecessary but I oculd live with it to close the issue. But I don’t want this to be a precedent for every other key type we support two
… Manu did make a compelling engineering argument for pem which is
… the crypto libraires that have existed for 20 years, openssl and friends, the microsoft ones all support it
… there is no such argument for any of the other key types

Dave Longley: We need to be careful, I’m interpreting for any other key types to mean for RSA. There is definitely that arguement for othe rkey types like ed25519 is represented using base58 everywhere, very common in lots of tools
… depends on the key type
… also don’t know if we want to say you MUST support both or one or the other, but could be an interop problem

Orie Steele: dave reminded me.. the thing that I would be sad about is if we had MUST support language for public keyJwk and must support language for publicKeyPem and yet
… lots of base58 encoded ed25519 keys floating around the ecosystem. That seems like a problem
… If there’s mUST support language for a certain key format in the spec it would be helpful to use those key formats
… becuase ther’es a deterministic process of converting any of these formats that aren’t pem or jwk I don’t understand why we wouldn’t just do that and help everyone along from the interop standpoint

Michael Jones: The more different things that you support, in practice the work your interop will be
… programmers are naturally going focus on the path they think they will use
… To your comment about lots of base58 stuff floating around for ed25519
… Manu as a discussion technique tried to focus us on RSA for a moment
… If for instance if we could all live with mandatory support for publicKeyPem and publicKeyJwk for RSA
… we might later decide to hold our nose and require mandatory support base58 encoding of ed25519 keys and mandatory support for the jwk encoding which is being done for webauthn among other things
… Making a decision about RSA doesn’t mean we’ve made a decision about variants of other elliptic curve key representations
… Although might argue we are setting a precedence of n being greater than 1

Yancy Ribbens: to Orie’s comment about why not just convert base58 keys to pem keys? base58 keys are specifically defined so that when users input the key they dont’ make certain kinds of mistakes
… I wonder if that would be lost of we were doing some type of conversion
… doesn’t seem like that would be a benefit

Dave Longley: Mike, I agree, I want to make sure of what you’re saying
… Also the decision for base58 has a lot to do with looking at documents and copying and pasting information. Eg. base64url behaves differently and could be more dangerous than copying base58, wans’t just about the number of characters available

Michael Jones: I appreciate the user interface benefits of using a restricted characater set. The auth device flow is a similar thing
… recommending that you don’t use 1 and l and 0 and O in your user interface character set
… to the extent that people are typing these things absolutely you have to think about the human factor stuff
… but the formats we’re talking about, nobody is going to type an asn.1 encoding
… nobody is going to try to type any of these long things, they will cut and paste it, we have computers that do a good job at that

Dave Longley: my understanding is that copy and paste is a problem for non-base58 as well (not just typing)

Michael Jones: So yes, if you’re doing a user interface for a wallet and you’re using a bitcoin key have at it. But that doesn’t mean the base58 doens’t get converted to a binary field of 256 bits which is trivial to base64url encode or do other things
… I would not support tyring to encode elliptic curve stuff as pem, it’s gratuitous

Dave Longley: also -1 to encoding the base58 keys as PEM

Orie Steele: from the ethereum ecosystem there’s tons of hexidecimal encoding stuff floating around
… people have become used to copying and pasting
… user experience broke up talkinga bout machine to machine interop that programmers are going to be relying on
… the hex encoded or base58 encoded, there are representations of both of them in jwk and those representations could be consistent and there’s a deterministic process of convering string representations to jwk format
… so nobody experiences these usability issues
… the machines can still interop
… let’s not talk about user interface issues, it’s data model

Dave Longley: let’s also not pretend humans don’t look at JSON documents

Dave Longley: +1 in general, but it’s not that cut and dry

Orie Steele: as soon as we make another choice than jwk we’re oging to have machine to machine interoperability issues
… I’m not in favour of adding any more, just sticking to JWK

Manu Sporny: Right before orie said that I was going to propsoe some PRs that we might have been able to process, but now I’m interested in what other people say
… I can put in a PR for where I thought we were with the RSA discussion.
… We’re to the point we can have a discussion around a PR

Oliver Terbu: +1 base58 solves a UX issue and we should stick with fewer formats

Manu Sporny: I’m going to try to do that for all key types, understanding we are not done with this discussion
… but maybe something more concrete will help tease some of these other arguements out
… Unless you think that’s a terrible idea?
… I’ll put in PRs for the three basic key types
… Anyone object and say it’s too early or we need another call?

Daniel Burnett: I don’t think that’s independant of having another call
… I see the value of doing that first, so there’s something more concrete
… We’re at that point where we need something specific ot look at to make progress
… If people have comments on next steps and timing?
… There is availability for next week around a similar time
… We could schedule another call for next week to continue this. Any thoughts?

Dmitri Zagidulin: The ed25519 question - whether we should support only jwk or any other formats
… i’d like to bring up kyle’s point about the relative size difference between a base58 encoding and a jwk

Michael Jones: I’m fine with having proposed PR text to review

Dave Longley: +1 to fixed set of formats per key type

Michael Jones: I would hope that in that PR text manu you would frame some of the choices with motivations saying that for each known key type there will be a fixed set of one or a small n of mandatory to support representations, to promote interoperability
… it wll not be extended for any existing key types

Manu Sporny: yep can do

Orie Steele: +1 to a fixed set of formats per key type

Dave Longley: and MUST support at least one (not sure about MUST support ALL)

Michael Jones: half of getting consensus is having everyone coming to a common understanding of why you’re making the deicsion, so to undo the decision you have to refute the rationale
… I’m fine with another call in a week

Orie Steele: +1 to MUST support at least one (not sure about MUST support ALL) as well

Michael Jones: The key size thing.. I think that was partly a confused discussion because they were comparing private key representations with public key representaitons, for RSA they’re an order of magnitude differnce
… for public key, base64url is smaller than base58

Oliver Terbu: +1 internal != external/public representation

Orie Steele: +1 internal != external/public representation

Brent Zundel: internal representation of a DID document doesn’t need to be the same as the public representation
… but we are out of time!

Markus Sabadello: +1 to brent

Brent Zundel: This conversation helped move things closer to consensus.

Dave Longley: +0 to internal != external/public … sometimes it may matter, need to be careful with that.

Dave Longley: (proofs on DID documents, etc.)