DIDWG Key formats/management call — Minutes

Date: 2019-12-04

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Amy Guy, Manu Sporny, Jonathan Holt, Michael Jones, Dave Longley, Markus Sabadello, Yancy Ribbens, Joe Andrieu, Ganesh Annan

Regrets:

Guests: joel

Chair: dan burnett

Scribe(s): Amy Guy

Content:

1. Spec updates

Manu Sporny: Which decisions to make spec updates?
… I think where we are today is we had a big long discussion and I think we narrowed in on some language specifically a number of proposals
… that seem to pass muster in this group, if not wider
… that helped us craft spec text changes
… the request on the call yesterday was to see if we can at least take the PRs that we have now
… I believe we have consensus around them modulo some changes mike and ted put in, mostly editorial
… but with those changes, see if we can merge those
… the assertion is not that we’re done
… it’s that what we have right now has consensus and is an improvement over where the current spec is today

Daniel Burnett: Right. Was not agreement on spec changes. Was for changes in the PRs. Minutes say “We had good consensus about pulling jwk out of the individual PRs and making its own general PR, would love to see that change before next call”

Manu Sporny: Any objections to merging what we have now?
… and then we can pick up the base58/base64url discussion, the jwk kid vs ldproofs/sigs id discussions
… there are other things we can make further updates with
… let’s get a stable foundation in

Michael Jones: I’m going to refine what manu said
… modulo I have to review one of the PRs for a change
… I’m fine merging them
… I think there’s consensus they’re better than what we have
… there’s not consensus for the base58 part of them
… the minutes shouldn’t reflect that there’s consensus for base58

Manu Sporny: I agree
… There isn’t consensus on base58 vs base64url
… For that reason I put in an issue marker in the text so it is very clear we don’t have consensus about it
… it exists in the spec, when we merge, an issue marker that says we’re still discussing it
… The table below is likely to change once we have a decision on that
… mike would that be okay?

Michael Jones: yes, I’m okay with the PRs

Daniel Burnett: Per the previous call notes there was broad but not complete support for base58. So not strong consensus as W3C requires

Manu Sporny: at this point I don’t know if it’s useful to go through the PRs again, there are many reviews and comments
… any editorial changes that people ant to have made ill be made before we merge
… specifically if it’s a normative change we need to talk, I don’t think there are any out there
… but any editorial stuff is included
… The other thing to understand about the PRs is there are 5 of them
… the first 100 is the base PR
… that adds a table and adds RSA and the language around jwk can be used for everything
… that’s the base foundational PR
… every other pr, 101 adds bitcoin/ethereum curves, 102 adds ed25519
… 109 adds secp256r1
… pr 110 adds curve25519
… basically they’ll all compress into one PR
… I just did different ones to make it easier to talk about them

Michael Jones: it doesn’t look like you applied my latest comments to 100

Manu Sporny: I will apply them if they’re editorial, I haven’t had chance to review

Michael Jones: you used the word native, it’s not correct

Manu Sporny: that’s fine

Michael Jones: default base encoding… I object to the word default, there are no defaults
… base encoding format used
… given this language is contentious I want to be as precise as possible

Manu Sporny: those sound okay to me
… if there are any surprises I won’t merge
… I don’t think we can merge without giving the WG some warning
… nothing in this group is binding, we have to notify the WG
… mike, there will be a period of 7 days before the PR is merged

Daniel Burnett: reminding people on IRC to do present+ if you haven’t

Michael Jones: the WG can ask for stuff to be pulled if we’re wrong. I don’t think we need to wait 7 days, we told them yesterday

Daniel Burnett: yesterday we said we’ll do it but if we make changes to anything different from what they had we do need to give more time
… just to be fair to those who were promised that any decisions, any discussions on this call resulting in decisions, will go back to the main group

Michael Jones: fine either way
… the only changes are to delete two words
… they’ve seen the normative content

Manu Sporny: I agree with burn, let’s just give everyone an opportunity to see the final version, including you, I’ll pull that stuff in
… then we can dust our hands of this set of PRs and move on to the next ones

Daniel Burnett: I don’t think it has to be 7 days
… it can be until the end of the next call

Manu Sporny: I’ll do that
… Any objections for merging all of the PRs, all 5, with all that said?
… at the end of next Tuesday

Dave Longley: +1 to merge all 5 PRs with conditions stated

Manu Sporny: +1 to merging all 5 PRs

Jonathan Holt: with the base58, one is just nomenclature, btc base58, there’s a slight difference from straight up base58
… trying to remember.. the prefix and the length in the addresses for bitcoin?

Dave Longley: base58 using the bitcoin alphabet

Manu Sporny: we’re not into the base58 discussion, that’s a discussion in and of itself. You’re right, that’s what we’ll have a discussion on but we need to clear this first

Jonathan Holt: but that’s in the PR

Manu Sporny: there’s an issue marker saying it’s base58 and it’s clear that it points to btc
… it’s in the issue marker, we have not decided we’re using base58btc yet, will have that discussion next
… right now we’re looking if anyone will object to the improvements we have consensus around right now

Jonathan Holt: all these PRs we’re just agreeing to pull them in

Manu Sporny: have until end of call next tues to object

Proposed resolution: Pull in PRs 100, 101, 102, 109, and 110 (with editorial changes) after the next DID WG call. (Manu Sporny)

Daniel Burnett: something about when editorial changes will be changed by.. the reason for the wait is so people can see the editorial changes

Proposed resolution: Pull in PRs 100, 101, 102, 109, and 110 (with editorial changes made by the end of Friday) after the next DID WG call. (Manu Sporny)

Manu Sporny: +1

Amy Guy: +1

Daniel Burnett: +1

Dave Longley: +1

Markus Sabadello: +1

Yancy Ribbens: +1

Jonathan Holt: +1

Michael Jones: +1

Resolution #1: Pull in PRs 100, 101, 102, 109, and 110 (with editorial changes made by the end of Friday) after the next DID WG call.

Michael Jones: I do think the wording of the issue you wrote it should probably be indicated that it’s a discussion not only what base encodings to support but under what circumstances we support them at all

Manu Sporny: you’re moving on to a base encodings discussion?

Michael Jones: no I’m talking about the text of pr 100
… you wrote an issue which assumed that there would be base encoding and it should be indicated in the issue that tha’ts still subject to discussion

Manu Sporny: it does say that

Manu Sporny: https://github.com/w3c/did-core/pull/100/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR1336

Manu Sporny: reads wording from ^

Michael Jones: that’s my point
… the issue assumes that there will be a base encoding format in all cases
… it’s not indicated that that’s still a matter of discussion
… maybe we can continue that next
… For which key types a base encoding will be supported and for which it won’t be
… this wording assumes there will always be one which I believe is incorrect
… I’ll propose an editorial change

Manu Sporny: thanks

2. Base Encoding Discussion

Manu Sporny: There’s a discussion around whether or not we’re going to use a base encoding mechanism and for which keys
… and if we do, which base encoding format should we use
… The items that have been proposed are base64url, base58btc and then a question of no base encoding
… I think mike you’re saying for pem formatted keys we say the encoding format is pem and not like base64?

Michael Jones: I also mean we may choose for some keys not to support anything that’s not jwk
… we always agreed that there would be one or more encodings specified and one is jwk but we haven’t agreed for any key types other than rsa to support another one
… There’s so much debate about base58 vs base64url vs hex vs lord knows what else that it’s not clear there’s consensus to include any of them

Manu Sporny: that is not what the PRs have in them
… there’s raw keys. it’s raw keys is where we had consensus. The only thing we had in question is what base encoding format do we use for raw keys

Michael Jones: base encoded keys are not raw keys, that’s not the same thing
… when we merge these need to be accurate as to what we have and haven’t agreed to

Manu Sporny: hmmm
… My concern is that I think we have consensus around using raw keys for the alternate formats
… for ed25519, secp.. and curve 25519
… I think I’m hearing you say we never agreed to that
… I think we did agree to that

Michael Jones: we never called those questions
… we could call those questions
… we had a general agreement that in some cases we would have second encodings but other than rsa we’ve never had the discussion on a case by case basis of which other key types we thin it’s advantageous to have another encoding and why
… I’m not trying to be difficult but let’s not charge ahead

Dave Longley: what we have a proposal for is standardise on jwk and a per key type format as the only two supported formats for at least rsa, sec256k1, secp256r1, ed25519 and curve25519. We did not say they’d have to be a particular base encoding
… From the minutes of 13th Nov

Michael Jones: I’m fine going with that then. Didn’t recall a discussion about the other key types but I guess the minutes say we did

Manu Sporny: My recollection is we did talk about it
… Does anyone feel like we’ll get consensus over anything other than raw key formats for k1, r1, ed25519 and curve25519

Dave Longley: say base encoded not raw key

Michael Jones: correct

Manu Sporny: so base encoded keys

Michael Jones: it’s a different discussion for each key type potentially, yes

Manu Sporny: in order to make this easier or to focus the discussion we have the alternate format for RSA
… it’s JWK or PEM
… I think we have consensus on that
… and then PEM has its own encoding which does use base64 but we don’t need to talk about it
… We need to talk about the 4 other keys
… We know that JWK works for all of them but there is a basically a 32 byte value that the other keys end up using
… the question is what base encoding format do we use for all of them / each of them?
… Would anyone disagree that we can just use the same base encoding format for all 4 to make things simple?
… One base encoding decision for all instead of taking them one by one?

Proposed resolution: We should use the same base-encoding format for secp256k1, secp256r1, ed25519, and curve25519 base-encoded public key values. (Manu Sporny)

Yancy Ribbens: +1

Dave Longley: +1

Manu Sporny: +1

Manu Sporny: Anyone object?

Jonathan Holt: +1

Dave Longley: I think that would be ideal

Michael Jones: No objection

Resolution #2: We should use the same base-encoding format for secp256k1, secp256r1, ed25519, and curve25519 base-encoded public key values.

Manu Sporny: then the question becomes what is the base encoding format?
… Currently base64url and base58 bitcoin have been proposed
… We straw polled last time and it was split
… We do need to discuss why one vs the other
… Mike would you like to start out by explaining why base64url would be the ideal candidate?

Michael Jones: base64url is based on an actual standard. It is widely deployed in the JSON world
… The only argument I’ve heard for base58 .. one is that some of the bitcoin UIs use it
… And that it’s easier to type in and get it correct
… Easier to type in and get it correct we’ve already discussed, they’re key representations are machine generated, not something people will type
… So it doesn’t apply
… If you have a UI and want to get people to type something in it’s entirely up to you how you do it, you could use braille, you could use base58, a qr code, that’s not what this is for
… Given that base64 is also more compact and it’s a standard, I think there’s a clear argument to use base64url

Dave Longley: one of the reasons we’re having multiple formats is to enable applications to not have to do anything new
… a lot of applications using secp256k1 (etc) are using base58 already as the format for transmitting keys
… I tend to disagree that the alphabet benefits don’t matter.
… that’s like saying there’s no reason for base58 to be created in the first place

Yancy Ribbens: +1 to more crypto libraries support base58 key encoding

Dave Longley: I think there will be cases where people will encounter and use these things
… given the fact that applications are already using this format, I think there’s a more significant cost to try and use this other format which cuts against the reason why we’re supporting this in the first place (base64url)
… I think there’s a greater cost there to saying let’s use that than going with what’s already in use
… we get the benefits of the alphabet if they ever were to apply
… Prefer to see base58
… -> https://tools.ietf.org/html/draft-msporny-base58 IETF draft document

Manu Sporny: there was an assertion that there wasn’t a spec, which was true but we put one together
… it’s a draft at IETF with no formal standing. It was a simple spec to put together
… For those that don’t know how base encoding works, it’s a fairly simple thing
… We’re not talking about massive implementation burdens
… with going with one thing over another
… if people are objecting I would assert there are no grounds to object over implementation burdens
… it’s the same algorithm, the only thing that changes is the alphabet and the divisor you’re using
… for base16, exact same algorithm
… most of the base encoding libs are implemented like this
… switching between one and another is very trivial
… Why base58?
… the introduction in the base58 outlines 6 reasons
… it’s fundamentally boils down to different requirements
… base58 had an additional set of reqs over base64url
… the first one was eliminating similar letters so you could type a value in
… I do agree that in some cases a human being is not going to see the value
… but the humans that do see the value and deal with them day to day such as myself and dlongley and anyone doing work on DIDs are developers
… the ability to visually check a value and check you’re not accidentally misreading a 0 and O or I and 1 is important
… keeps you from making mistakes as a developer
… Important to note that by eliminating the +=/ chars you make it possible to take these values and write them directly to disc in a filesystem
… that might not seem important, but for example our DID client, the did-cli thing, when it creates a DID it will write the private key encrypted on disc using the DID as an identifier
… Using for v1 it’s a base58 encoded value. It makes it really simple to write it to disc without doing yet another translation
… Important in did:v1 important in did:key and hopefully a variety of other ed25519 and secp k1 r1 did implementations
… another usability othing is for copying and pasting values
… social messaging systems don’t line break on base 58 chars, so you can double click or highlight or see the value
… The other thing to keep in mind, a nerdy detail, unlike base64, base58 doesn’t have padding
… which means for values up to 64 bytes it’s just as efficient to encode
… for above that it’s a 2% penalty
… base64 has 11 encoding variations
… when you say base64 you could mean 11 different things. base64url is more specific, but developers get which base64 version they’re using wrong
… in a library the alphabet is different, or is some variation
… base58 libraries are very strict about what they do, almost everyone does base58 bitcoin
… flickr do their own thing, we call that out as unsupported
… There are 6 additional requirements and use cases that base58 covers, that base64url does not
… the assertion is that those use cases matter
… which is why we should use base58

Michael Jones: there’s a bunch of things that are not true
… base64url has no padding
… there is only one base64url encoding
… it’s specified in an RFC in the 4000 range
… RFC7515. No ambiguity there
… I agree that developers can get this wrong if they just read base64 and forget what they’re doing
… That’s why the openID certification suite has tests to make sure you’re using the correct alphabet
… We could do the same in our test suite
… To the extend we’re using JWKs we should include those texts to make sure the base64url encoded binary values are correctly encoded
… to dave’s point a long time ago, a rhetorical point that there’s no reason for base58 to have been created. That’s not true. It was created for UI purposes
… I understand the value of that
… I was the coauthor of the oauth device flow spec where we recommend that codes entered by humans use a restricted alphabet to prevent unknown typos
… We recommend not using 0 1 L or O at all. Not saying what encoding to use, just providing UI guidelines.
… So for UI purposes I’m fine with you using base58 or braille or qr codes
… But i would rather we stick with using an actual standard in our standard
… Yeah it might be a change to some code but as manu said these things are trivial
… base64 is more trivial cos there’s more libraries for it
… I know you wrote a spec that’s an individual drafts, we can’t refer to that as authoritative in a w3c rec
… if we do decided to keep some form of base58 we need to pull it into our draft or have another w3c spec or get that draft completed
… unless you can get satoshi to make an IPR declaration you can’t have him as a coauthor or the IETF process will reject your draft

Markus Sabadello: I know we just agreed to use the same encoding for all four key types
… I think base58 encoding is the most popular encoding for curve25519 keys
… it’s also popular for bitcoin and ethereum address
… but not sure if it’s popular for bitcoin and ethereum keys
… if I look at the keys more often it’s hex encoding
… Wondering if we wanted to choose what is the most popular encoding for the respective key types or we don’t want to use hex because of size constraints
… or the same encoding for simplicity
… not feel strongly, just wondering

Yancy Ribbens: I want to say that working as a software engineer I do run into far more crypto libraries, eg. lib-sodium and such, that use base58 encoding
… Secondly I want to say there’s an additional benefit that I’m not sure manu got in his draft
… base58 does basic CRC checking, so more to error prevention than just minimised alphabets
… bitcoin keys are base58 but I think ethereum is not

Yancy Ribbens: having audio issues

Manu Sporny: to clarify points mike was making

Manu Sporny: See https://tools.ietf.org/html/rfc4648#section-5

Manu Sporny: I looked at the base64url encoding section in the spec and it’s got padding
… that’s minor, we don’t need to go into it

Dave Longley: i think strongest argument to me is that one big reason we’re adding these other formats is to support existing application code … so we should use what those applications are using (PEM for RSA, base58 for ed25519/x25519, …)

Manu Sporny: Did want to refer to we can’t point to drafts .. you can in certain circumstances if the draft is not going to change and you can convince w3c that’s true
… we can also pull it into the spec or create a different spec without issue
… but putting it as an ID at IETF and that it follows the base58 implementations, which haven’t changed in a decade
… it’s stable and well implemented
… I don’t think we’ll have an issue with that
… putting satoshi as a coauthor was a joke
… we can take it off
… it was also a nod to the person who thought about those benefits and put it in the source code
… whatever IETF process, if IETF doesn’t allow us to keep his name we can take it off and move forward anyway

Michael Jones: “Base64url Encoding Base64 encoding using the URL- and filename-safe character set defined in Section 5 of RFC 4648 [RFC4648], with all trailing ‘=’ characters omitted (as permitted by Section 3.2) and without the inclusion of any line breaks, whitespace, or other additional characters. Note that the base64url encoding of the empty octet sequence is the empty string. (See Appendix C for notes on implementin[CUT]”

Michael Jones: I pasted the definition used in the JWS and related specs into IRC
… We explicitly say you’re not to use padding

Manu Sporny: we’re not talking about what that spec said, we’re talking about a standard base encoding
… you could say base64url as defined by JWS but that is not the standard base64url
… base64url does allow you to say no padding in another spec. I’m just highlighting this is the confusion

Michael Jones: in the JSON world that’s what’s used
… We would just reference 7515 if you believe there’s ambiguity

Manu Sporny: I’m wondering if we could do a proposal and if it would lead anywhere

Dave Longley: perhaps more specifically said… in the JOSE world (vs. in the JSON world)

Michael Jones: You can read the base64url definition at https://tools.ietf.org/html/rfc7515#section-2

Daniel Burnett: this does not seem to be going anywhere, not sure how to get further
… one thing we could do is seek a broader audience
… we have done this before
… where you put up an issue, base58 vs base64url and do a straw poll voting in the issue
… let’s the world comment and get to see who has various opinions
… there are arguments that are reasonable in both directions, just which ones do you think are more relevant today

Dave Longley: DID method implementers are already using base58 for at least two of these key types
… That’s another piece of information we should take into consideration
… as opposed to having people switch

Yancy Ribbens: base58 is more common in practice in the wild
… it may not be as well specified as base64 in practice i see it more used
… I don’t know if in manu’s draft he also mentioned there’’s built in error correcting functionality for base58 encoding which would be a 7th reason that it’s useful

Manu Sporny: can we get some data?
… I have no idea what other people are thinking
… would be good to get that input from the call and move it out to the WG
… am concerned about just asking anyone, it should be up to DID implementers
… who is implementing a DID method, what do they want to implement, whenever we have discussions where you could go one way or the other
… it’s good to ask the implementers and weigh their feedback more than random people off the internet
… Can we do a straw poll

Manu Sporny: STRAW POLL: Which would you prefer to see as the base-encoding mechanism for non-JWK public key values in the DID Core specification (options: base64url or base58btc)

Michael Jones: there’s a process point I feel strongly about - if the implementers are in the WG we should ask them
… but this is a WG decision not a developer decision
… all decisions about this spec should be made by WG participants
… so asking developers who aren’t members of the WG is really not following the w3c process

Daniel Burnett: Implementers is what matters
… W3C has been clear on that
… it’s a member org because we need to know what the actual implementers will think, and they tend to be the companies that will join w3c
… however we get data, it does need to be clear whether this is developers, implementers for themselves, implementers representing a larger developer pool, etc

Michael Jones: sure but for instance in today’s job I’m not an implementer but I’m representing dozens of them
… I don’t want to belabour this but manu’s wording made it sound like we would just send mail to random DID implementer mailing lists

Daniel Burnett: I don’t believe manu was ever suggesting that

Manu Sporny: correct
… I was not suggesting that

Michael Jones: if we’re sending a message to w3c-public-did mailing list that’s appropriate

Manu Sporny: yep

Manu Sporny: STRAW POLL: Which would you prefer to see as the base-encoding mechanism for non-JWK public key values in the DID Core specification (options: base64url or base58btc)

Manu Sporny: can we quickly get some data on the straw poll?

Manu Sporny: +1 base58btc

Michael Jones: base64url

Dave Longley: +1 base58btc - as an implementer, i would strongly prefer base58 for ed25519, x25519 keys (i would object to base64url for those key types)

Yancy Ribbens: +1 base58btc

Jonathan Holt: +1 base58btc

Jonathan Holt: it really doesn’t matter, in the end

Markus Sabadello: +1 base58btc for ed25519 and x25519, but not sure about base58btc for secp256* keys yet

Daniel Burnett: this is just to collect data

Manu Sporny: next step is to circulate on the mailing list and get a broader constituency to have an opinion

Dave Longley: i’m mostly with markus here

Jonathan Holt: I’m a physician by training, but as a physician I can parse base58 and base64 trivially, I don’t think a real developer is going to trip up on it

Daniel Burnett: thanks everyone, progress!

3. Resolutions