DIDWG Key formats/management call -- 04 Dec 2019

scribe+

manu: 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 i nthis 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

<burn> 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: it's that what we have right now has consensus and is an improvement over where the current spec is today
... Any objectiosn 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

<manu> https://github.com/w3c/did-core/pull/100

<manu> https://github.com/w3c/did-core/pull/101

<manu> https://github.com/w3c/did-core/pull/102

selfissued: I'm going to refine what manu said

<manu> https://github.com/w3c/did-core/pull/109

selfissued: modulo I have ot review one of the PRs for a change
... I'm fine merging them

<manu> https://github.com/w3c/did-core/pull/110

selfissued: 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

<Zakim> manu, you wanted to speak to base58

manu: 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' thave consensus about it
... it exists in the spec, when we merge, an issue marker that says ew're still discussing it
... The table below is likely to change once we have a decision on that
... mike would that be okay?

selfissued: yes, I'm okay with the PRs

<burn> Per the previous call notes there was broad but not complete support for base58. So not strong consensus as W3C requires

manu: 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 peoplw ant to have madew 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

<manu> https://github.com/w3c/did-core/pull/100

manu: 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

selfissued: it doesn't look like you applied my latest comments to 100

manu: I will apply them if they're editorial, I haven't had chance to review

selfissued: you used the word native, it's not correct

manu: that's fine

selfissued: 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: those sound okay to me
... i fthere 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

<Zakim> burn, you wanted to discuss admin

burn: reminding people on IRC to do present+ if you haven't

<yancy> preeesent+

selfissued: 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

burn: 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 deciisions, will go back to the main group

selfissued: fine either way
... the only changes are to delete two words
... they've seen the normative content

manu: 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

burn: I don't think it has to be 7 days
... it can be until the end of the next call

manu: I'll do that
... Any objections for merging all of the PRs, all 5, with all that said?
... at the end of next tuesday

<dlongley> +1 to merge all 5 PRs with conditions stated

<manu> +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?

<dlongley> base58 using the bitcoin alphabet

manu: 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: 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 imporvements we have consensus around right now

jonathan_holt: all these PRs we're just agreeing to pull them in

manu: have until end of call next tues to object

<manu> PROPOSAL: Pull in PRs 100, 101, 102, 109, and 110 (with editorial changes) after the next DID WG call.

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

<manu> PROPOSAL: 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> +1

<burn> +1

<dlongley> +1

<markus_sabadello> +1

<yancy> +1

<jonathan_holt> +1

<selfissued> +1

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.

selfissued: 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: you're moving on to a base encodings discussion?

selfissued: 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: it does say that

<manu> https://github.com/w3c/did-core/pull/100/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR1336

manu: *reads wording from ^*

selfissued: 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: thanks

Base Encoding Discussion

manu: There's a discussion around whehter 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?

selfissued: 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: 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 si what base encoding format do we use for raw keys

selfissued: 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: 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

selfissued: 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 adventageous to have another encoding and why
... I'm not trying to be difficult but let's not charge ahead

dlongley: what we have a prposal 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 paritcular base encoding
... From the minutes of 13th Nov

selfissued: 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: 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

dlongley: say base encoded not raw key

selfissued: correct

manu: so base encoded keys

selfissued: it's a different discussion for each key type potentially, yes

manu: 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?

<manu> PROPOSAL: We should use the same base-encoding format for secp256k1, secp256r1, ed25519, and curve25519 base-encoded public key values.

<yancy> +1

<dlongley> +1

<manu> +1

manu: Anyone object?

<jonathan_holt> +1

dlongley: I think that would be ideal

<selfissued> No objection

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

manu: 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?

selfissued: base64url is based on an actual standard. It is widely deployed in the JSON world
... The only arguement 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, theys 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 somethign 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

<Zakim> dlongley, you wanted to say base58 is commonly used for secp256k1, ed25519, and curve25519 (x25519) and has additional alphabet benefits

dlongley: one of the reasons we'r ehaving 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 transimitting 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> +1 to more crypto libraries support base58 key encoding

dlongley: 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)
... Ithink 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

<Zakim> manu, you wanted to make a case for base58.

dlongley: Prefer to see base58

<manu> https://tools.ietf.org/html/draft-msporny-base58

manu: 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 formatl 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 th edivisor 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?

<manu> https://tools.ietf.org/html/draft-msporny-base58

manu: 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 ifrst 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
... tha tmight 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

selfissued: 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 deicded to keep some form of base58 we need to pull it into our draft or have another w3c spec or get that draft copmleted
... unless you can get satoshi to make an IPR declaration you can't have him as a coauthor or th eIETF 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 respectiv ekey 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: 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

<Zakim> manu, you wanted to say that base64url does include padding. and to speak to "drafts as W3C spec". and to note that Satoshi was tongue in cheek.

<yancy> having audio issues

manu: to clarify points mike was making

<manu> https://tools.ietf.org/html/rfc4648#section-5

manu: 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

<dlongley> 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: Did want to refer to we can't point to drafts .. you can in certian 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 havne't changed in a decade
... it's stable and well implemented
... I dont 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 tohught 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

<selfissued> 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]

selfissued: I pasted the definition used in the JWS and related specs into IRC
... We explicitly say you're not to use padding

manu: 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 lalow you to say no padding in another spec. I'm just highlighting this is the confusion

selfissued: in the JSOn world that's what's used
... We would just reference 7515 if you believe there's ambiguity

manu: I'm wondering if we could do a proposal and if it would lead anywhere

<dlongley> perhaps more specifically said... in the JOSE world (vs. in the JSON world)

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

burn: this does not seem to be going anywhere, not sure how to get futher
... 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 variosu opinions
... there are arguements that are reasonable in both directions, just which ones do you think are more relevant today

<Zakim> dlongley, you wanted to say DID method implementers are already using base58

dlongley: DID method implementers ar ealready using base58 for at least two of these key types
... Tha'ts another piece of information we should take into consideration
... as opposed to having people switch

yancy: 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

<Zakim> manu, you wanted to straw poll... just so we have some data... and to worry about getting input from non-implementers.

manu: can we get some data?
... I have no idea what other pepole 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> 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)

selfissued: there's sa 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 devs who aren't members of the WG is really not following the w3c process

burn: Implementers is what mattres
... W3C has been clear on that
... it's a member org because we need to knwo 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

selfissued: 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

burn: I don't believe manu was ever suggesting that

manu: correct
... I was not suggesting that

selfissued: if we're sending a message to w3c-public-did mailing list that's appropriate

manu: yep

<manu> 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: can we quickly get some data on the straw poll?

<manu> +1 base58btc

<selfissued> base64url

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

<yancy> +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

burn: this is just to collect data

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

<dlongley> 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

burn: thanks everyone, progress!

- DRAFT -

DIDWG Key formats/management call

04 Dec 2019

Attendees

Contents

Base Encoding Discussion

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output