16:45:54 RRSAgent has joined #did 16:45:54 logging to https://www.w3.org/2019/12/04-did-irc 16:46:27 Meeting: DIDWG Key formats/management call 16:46:33 Chair: Dan_Burnett 16:46:43 rrsagent, draft minutes 16:46:43 I have made the request to generate https://www.w3.org/2019/12/04-did-minutes.html burn 16:47:01 rrsagent, make logs public 16:47:29 present+ 17:00:27 jonathan_holt has joined #did 17:01:26 present+ 17:01:29 scribe+ 17:01:33 present+ 17:01:52 present+ jonathan_holt 17:02:17 selfissued has joined #did 17:02:21 present+ 17:02:23 present+ 17:03:03 markus_sabadello has joined #did 17:03:12 present+ 17:04:44 q+ 17:04:57 ack manu 17:05:10 manu: Which decisions to make spec updates? 17:05:28 ... 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 17:05:35 ... that seem to pass muster i nthis group, if not wider 17:05:40 ... that helped us craft spec text changes 17:05:51 ... the request on the call yesterday was to see if we can at least take the PRs that we have now 17:06:02 ... I believe we have consensus around them modulo some changes mike and ted put in, mostly editorial 17:06:08 ... but with those changes, see if we can merge those 17:06:11 ... the assertion is not that we're done 17:06:14 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" 17:06:22 ... it's that what we have right now has consensus and is an improvement over where the current spec is today 17:06:23 q+ 17:06:30 ... Any objectiosn to merging what we have now? 17:06:46 ... and then we can pick up the base58/base64url discussion, the jwk kid vs ldproofs/sigs id discussions 17:06:51 ... there are other things we can make further updates with 17:06:54 ... let's get a stable foundation in 17:07:01 https://github.com/w3c/did-core/pull/100 17:07:02 ack selfissued 17:07:04 https://github.com/w3c/did-core/pull/101 17:07:08 https://github.com/w3c/did-core/pull/102 17:07:08 selfissued: I'm going to refine what manu said 17:07:12 https://github.com/w3c/did-core/pull/109 17:07:14 ... modulo I have ot review one of the PRs for a change 17:07:17 ... I'm fine merging them 17:07:18 https://github.com/w3c/did-core/pull/110 17:07:22 ... I think there's consensus they're better than what we have 17:07:27 ... there's not consensus for the base58 part of them 17:07:34 ... the minutes shouldn't reflect that there's consensus for base58 17:07:34 q+ to speak to base58 17:07:37 ack manu 17:07:37 manu, you wanted to speak to base58 17:07:41 manu: I agree 17:07:48 ... There isn't consensus on base58 vs base64url 17:07:57 ... For that reason I put in an issue marker in the text so it is very clear we don' thave consensus about it 17:07:59 q+ 17:08:06 ... it exists in the spec, when we merge, an issue marker that says ew're still discussing it 17:08:13 ... The table below is likely to change once we have a decision on that 17:08:16 ... mike would that be okay? 17:08:25 selfissued: yes, I'm okay with the PRs 17:08:34 Per the previous call notes there was broad but not complete support for base58. So not strong consensus as W3C requires 17:08:47 manu: at this point I don't know if it's useful to go through the PRs again, there are many reviews and comments 17:08:48 q? 17:08:54 ... any editorial changes that peoplw ant to have madew ill be made before we merge 17:09:04 ... specifically if it's a normative change we need to talk, I don't think there are any out there 17:09:08 ... but any editorial stuff is included 17:09:14 ... The other thing to understand about the PRs is there are 5 of them 17:09:17 https://github.com/w3c/did-core/pull/100 17:09:18 q+ for admin 17:09:20 ... the first 100 is the base PR 17:09:31 ... that adds a table and adds RSA and the language around jwk can be used for everything 17:09:34 ... that's the base foundational PR 17:09:45 ... every other pr, 101 adds bitcoin/ethereum curves, 102 adds ed25519 17:09:54 ... 109 adds secp256r1 17:10:00 ... pr 110 adds curve25519 17:10:07 ... basically they'll all compress into one PR 17:10:12 ... I just did different ones to make it easier to talk about them 17:10:17 q+ 17:10:20 ack selfissued 17:10:31 selfissued: it doesn't look like you applied my latest comments to 100 17:10:39 manu: I will apply them if they're editorial, I haven't had chance to review 17:10:44 selfissued: you used the word native, it's not correct 17:10:46 manu: that's fine 17:10:57 selfissued: default base encoding... I object to the word default, there are no defaults 17:11:01 ... base encoding format used 17:11:07 ... given this language is contentious I want to be as precise as possible 17:11:10 manu: those sound okay to me 17:11:14 ... i fthere are any surprises I won't merge 17:11:20 ... I don't think we can merge without giving the WG some warning 17:11:26 ... nothing in this group is binding, we have to notify the WG 17:11:33 ... mike, there will be a period of 7 days before the PR is merged 17:11:35 ack burn 17:11:35 burn, you wanted to discuss admin 17:11:50 burn: reminding people on IRC to do present+ if you haven't 17:11:58 preeesent+ 17:12:18 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 17:12:39 q+ 17:12:40 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 17:12:57 joel has joined #did 17:12:57 ... 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 17:12:59 selfissued: fine either way 17:13:05 ... the only changes are to delete two words 17:13:06 present+ 17:13:09 ... they've seen the normative content 17:13:27 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 17:13:34 ... then we can dust our hands of this set of PRs and move on to the next ones 17:13:37 burn: I don't think it has to be 7 days 17:13:42 ... it can be until the end of the next call 17:13:46 manu: I'll do that 17:14:16 q+ 17:14:16 ... Any objections for merging all of the PRs, all 5, with all that said? 17:14:23 ... at the end of next tuesday 17:14:24 +1 to merge all 5 PRs with conditions stated 17:14:24 ack selfissued 17:14:34 ack jonathan_holt 17:14:39 +1 to merging all 5 PRs 17:14:41 present+ 17:14:54 jonathan_holt: with the base58, one is just nomenclature, btc base58, there's a slight difference from straight up base58 17:15:02 q+ 17:15:04 ... trying to remember.. the prefix and the length in the addresses for bitcoin? 17:15:06 ack manu 17:15:11 base58 using the bitcoin vocabulary 17:15:19 s/vocabulary/alphabet 17:15:21 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 17:15:24 jonathan_holt: but that's in the PR 17:15:34 manu: there's an issue marker saying it's base58 and it's clear that it points to btc 17:15:46 ... it's in the issue marker, we have not decided we're using base58btc yet, will have that discussion next 17:15:56 ... right now we're looking if anyone will object to the imporvements we have consensus around right now 17:16:06 jonathan_holt: all these PRs we're just agreeing to pull them in 17:16:22 manu: have until end of call next tues to object 17:17:51 PROPOSAL: Pull in PRs 100, 101, 102, 109, and 110 (with editorial changes) after the next DID WG call. 17:18:24 burn: something about when editorial changes will be changed by.. the reason for the wait is so people can see the editorial changes 17:18:45 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. 17:18:57 +1 17:19:01 +1 17:19:02 +1 17:19:05 +1 17:19:07 +1 17:19:12 +1 17:19:13 +1 17:20:22 +1 17:20:30 q+ 17:20:39 RESOLVED: Pull in PRs 100, 101, 102, 109, and 110 (with editorial changes made by the end of Friday) after the next DID WG call. 17:21:03 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 17:21:12 manu: you're moving on to a base encodings discussion? 17:21:17 selfissued: no I'm talking about the text of pr 100 17:21:32 ... 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 17:21:34 manu: it does say that 17:22:06 https://github.com/w3c/did-core/pull/100/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR1336 17:22:17 manu: *reads wording from ^* 17:22:31 selfissued: that's my point 17:22:38 ... the issue assumes that there will be a base encoding format in all cases 17:22:46 ... it's not indicated that that's still a matter of discussion 17:22:51 ... maybe we can continue that next 17:22:59 ... For which key types a base encoding will be supported and for which it won't be 17:23:06 ... this wording assumes there will always be one which I believe is incorrect 17:23:11 ... I'll propose an editorial change 17:23:12 manu: thanks 17:23:13 q? 17:23:16 ack selfissued 17:23:19 Topic: Base Encoding Discussion 17:23:19 TOPIC: base encoding discussion 17:23:35 manu: There's a discussion around whehter or not we're going to use a base encoding mechanism and for which keys 17:23:42 ... and if we do, which base encoding format should we use 17:23:56 ... The items that have been proposed are base64url, base58btc and then a question of no base encoding 17:24:09 ... I think mike you're saying for pem formatted keys we say the encoding format is pem and not like base64? 17:24:18 selfissued: I also mean we may choose for some keys not to support anything that's not jwk 17:24:37 ... 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 17:24:53 ... 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 17:24:56 manu: that is not what the PRs have in them 17:25:13 ... 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 17:25:21 selfissued: base encoded keys are not raw keys, that's not the same thing 17:25:34 ... when we merge these need to be accurate as to what we have and haven't agreed to 17:25:35 q? 17:25:37 manu: hmmm 17:25:38 q+ 17:25:56 ... My concern is that I think we have consensus around using raw keys for the alternate formats 17:25:56 ack manu 17:26:07 ... for ed25519, secp.. and curve 25519 17:26:12 ... I think I'm hearing you say we never agreed to that 17:26:15 ... I think we did agree to that 17:26:19 selfissued: we never called those questions 17:26:21 ... we could call those questions 17:26:44 ... 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 17:26:50 ... I'm not trying to be difficult but let's not charge ahead 17:27:25 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 17:27:35 ... From the minutes of 13th Nov 17:27:50 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 17:27:56 manu: My recollection is we did talk about it 17:28:17 ... Does anyone feel like we'll get consensus over anything other than raw key formats for k1, r1, ed25519 and curve25519 17:28:21 dlongley: say base encoded not raw key 17:28:24 selfissued: correct 17:28:26 manu: so base encoded keys 17:29:08 selfissued: it's a different discussion for each key type potentially, yes 17:29:24 manu: in order to make this easier or to focus the discussion we have the alternate format for RSA 17:29:26 ... it's JWK or PEM 17:29:29 ... I think we have consensus on that 17:29:39 ... and then PEM has its own encoding which does use base64 but we don't need to talk about it 17:29:43 ... We need to talk about the 4 other keys 17:29:57 ... 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 17:30:05 ... the question is what base encoding format do we use for all of them / each of them? 17:30:15 ... Would anyone disagree that we can just use the same base encoding format for all 4 to make things simple? 17:30:26 ... One base encoding decision for all instead of taking them one by one? 17:31:18 PROPOSAL: We should use the same base-encoding format for secp256k1, secp256r1, ed25519, and curve25519 base-encoded public key values. 17:31:21 +1 17:31:24 +1 17:31:25 +1 17:31:32 manu: Anyone object? 17:31:33 +1 17:31:35 dlongley: I think that would be ideal 17:32:08 No objection 17:32:18 RESOLVED: We should use the same base-encoding format for secp256k1, secp256r1, ed25519, and curve25519 base-encoded public key values. 17:32:26 manu: then the question becomes what is the base encoding format? 17:32:34 ... Currently base64url and base58 bitcoin have been proposed 17:32:47 ... We straw polled last time and it was split 17:32:52 ... We do need to discuss why one vs the other 17:33:02 ... Mike would you like to start out by explaining why base64url would be the ideal candidate? 17:33:11 q+ to say base58 is commonly used for secp256k1, ed25519, and curve25519 (x25519) and has additional alphabet benefits 17:33:14 selfissued: base64url is based on an actual standard. It is widely deployed in the JSON world 17:33:28 ... The only arguement I've heard for base58 .. one is that some of the bitcoin UIs use it 17:33:34 ... And that it's easier to type in and get it correct 17:33:37 present+ ganesh 17:33:51 ... Easier to type in and get it correct we've already discussed, theys key representations are machine generated, not something people will type 17:33:55 ... So it doesn't apply 17:34:14 ... 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 17:34:17 q+ to make a case for base58. 17:34:26 ... Given that base64 is also more compact and it's a standard, I think there's a clear argument to use base64url 17:34:27 ack dlongley 17:34:27 dlongley, you wanted to say base58 is commonly used for secp256k1, ed25519, and curve25519 (x25519) and has additional alphabet benefits 17:34:40 dlongley: one of the reasons we'r ehaving multiple formats is to enable applications to not have to do anything new 17:34:59 ... a lot of applications using secp256k1 (etc) are using base58 already as the format for transimitting keys 17:35:06 ... I tend to disagree that the alphabet benefits don't matter. 17:35:14 ... that's like saying there's no reason for base58 to be created in the first place 17:35:16 q+ 17:35:17 +1 to more crypto libraries support base58 key encoding 17:35:21 ... I think there will be cases where people will encounter and use these things 17:35:40 ... 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) 17:35:48 ... Ithink there's a greater cost there to saying let's use that than going with what's already in use 17:35:56 q+ 17:35:57 ... we get the benefits of the alphabet if they ever were to apply 17:35:59 ack manu 17:35:59 manu, you wanted to make a case for base58. 17:36:00 ... Prefer to see base58 17:36:05 https://tools.ietf.org/html/draft-msporny-base58 17:36:11 manu: there was an assertion that there wasn't a spec, which was true but we put one together 17:36:22 ... it's a draft at IETF with no formatl standing. IT was a simple spec to put together 17:36:32 ... For those that don't know how base encoding works, it's a fairly simple thing 17:36:37 ... We're not talking about massive implementation burdens 17:36:40 ... with going with one thing over another 17:36:51 ... if people are objecting I would assert there are no grounds to object over implementation burdens 17:37:02 ... it's the same algorithm, the only thing that changes is the alphabet and th edivisor you're using 17:37:14 ... for base16, exact same algorithm 17:37:20 ... most of the base encoding libs are implemented like this 17:37:24 ... switching between one and another is very trivial 17:37:28 ... Why base58? 17:37:31 https://tools.ietf.org/html/draft-msporny-base58 17:37:41 ... the introduction in the base58 outlines 6 reasons 17:37:48 ... it's fundamentally boils down to different requirements 17:37:54 ... base58 had an additional set of reqs over base64url 17:38:04 ... the ifrst one was eliminating similar letters so you could type a value in 17:38:14 ... I do agree that in some cases a human being is not going to see the value 17:38:32 ... 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 17:38:44 ... the ability to visually check a value and check you're not accidentally misreading a 0 and O or I and 1 is important 17:38:50 ... keeps you from making mistakes as a developer 17:39:04 ... 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 17:39:16 q+ 17:39:23 ... 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 17:39:37 ... Using for v1 it's a base58 encoded value. It makes it really simple to write it to disc without doing yet another translation 17:39:55 ... Important in did:v1 important in did:key and hopefully a variety of other ed25519 and secp k1 r1 did implementations 17:40:04 ... another usability othing is for copying and pasting values 17:40:16 ... social messaging systems don't line break on base 58 chars, so you can double click or highlight or see the value 17:40:25 ... The other thing to keep in mind, a nerdy detail, unlike base64, base58 doesn't have padding 17:40:41 ... which means for values up to 64 bytes it's just as efficient to encode 17:40:47 ... for above that it's a 2% penalty 17:41:11 ... base64 has 11 encoding variations 17:41:25 ... when you say base64 you could mean 11 different things. base64url is more specific, but developers get which base64 version they're using wrong 17:41:34 ... in a library the alphabet is different, or is some variation 17:41:44 ... base58 libraries are very strict about what they do, almost everyone does base58 bitcoin 17:41:51 ... flickr do their own thing, we call that out as unsupported 17:42:01 ... There are 6 additional requirements and use cases that base58 covers, that base64url does not 17:42:02 q+ 17:42:06 ... the assertion is that those use cases matter 17:42:10 ... which is why we should use base58 17:42:17 ack selfissued 17:42:26 selfissued: there's a bunch of things that are not true 17:42:33 ... base64url has no padding 17:42:40 ... there is only one base64url encoding 17:42:47 ... it's specified in an RFC in the 4000 range 17:42:58 ... RFC7515. No ambiguity there 17:43:09 ... I agree that developers can get this wrong if they just read base64 and forget what they're doing 17:43:20 ... That's why the openID certification suite has tests to make sure you're using the correct alphabet 17:43:22 q? 17:43:24 ... We could do the same in our test suite 17:43:39 ... To the extend we're using JWKs we should include those texts to make sure the base64url encoded binary values are correctly encoded 17:43:58 ... 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 17:44:02 ... I understand the value of that 17:44:19 ... 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 17:44:32 ... We recommend not using 0 1 L or O at all. Not saying what encoding to use, just providing UI guidelines. 17:44:44 ... So for UI purposes I'm fine with you using base58 or braille or qr codes 17:44:52 ... But i would rather we stick with using an actual standard in our standard 17:44:58 q+ base64url does include padding. 17:45:01 ... Yeah it might be a change to some code but as manu said these things are trivial 17:45:03 q+ to say that base64url does include padding. 17:45:06 ... base64 is more trivial cos there's more libraries for it 17:45:32 ... I know you wrote a spec that's an individual drafts, we can't refer to that as authoritative in a w3c rec 17:45:47 q+ to speak to "drafts as W3C spec". 17:45:51 ... 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 17:45:59 q+ to note that Satoshi was tongue in cheek. 17:46:05 ack markus_sabadello 17:46:07 ... 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 17:46:18 markus_sabadello: I know we just agreed to use the same encoding for all four key types 17:46:27 ... I think base58 encoding is the most popular encoding for curve25519 keys 17:46:33 ... it's also popular for bitcoin and ethereum address 17:46:38 ... but not sure if it's popular for bitcoin and ethereum keys 17:46:45 ... if i look at the keys more often it's hex encoding 17:47:03 ... 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 17:47:07 ... or the same encoding for simplicity 17:47:09 ack yancy 17:47:11 ... not feel strongly, just wondering 17:47:35 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 17:47:44 ... Secondly I want to say there's an additional benefit that I'm not sure manu got in his draft 17:47:54 q? 17:47:56 ... base58 does basic CRC checking, so more to error prevention than just minimised alphabets 17:48:04 ... bitcoin keys are base58 but I think ethereum is not 17:48:27 ack manu 17:48:27 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. 17:48:29 having audio issues 17:48:34 q+ 17:48:41 manu: to clarify points mike was making 17:48:47 https://tools.ietf.org/html/rfc4648#section-5 17:48:51 ... I looked at the base64url encoding section in the spec and it's got padding 17:48:58 ... that's minor, we don't need to go into it 17:49:14 q+ 17:49:18 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, ...) 17:49:20 ... 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 17:49:29 ... we can also pull it into the spec or create a different spec without issue 17:49:42 ... but putting it as an ID at IETF and that it follows the base58 implementations, which havne't changed in a decade 17:49:46 ... it's stable and well implemented 17:49:49 ... I dont think we'll have an issue with that 17:49:55 ... putting satoshi as a coauthor was a joke 17:49:57 ... we can take it off 17:50:06 ... it was also a nod to the person who tohught about those benefits and put it in the source code 17:50:16 ... whatever IETF process, if IETF doesn't allow us to keep his name we can take it off and move forward anyway 17:50:18 ack yancy 17:50:18 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] 17:50:40 ack selfissued 17:50:55 selfissued: I pasted the definition used in the JWS and related specs into IRC 17:51:07 ... We explicitly say you're not to use padding 17:51:10 q? 17:51:17 manu: we're not talking about what that spec said, we're talking about a standard base encoding 17:51:25 ... you could say base64url as defined by JWS but that is not the standard base64url 17:51:37 ... base64url does lalow you to say no padding in another spec. I'm just highlighting this is the confusion 17:51:42 selfissued: in the JSOn world that's what's used 17:51:50 ... We would just reference 7515 if you believe there's ambiguity 17:52:08 manu: I'm wondering if we could do a proposal and if it would lead anywhere 17:52:11 perhaps more specifically said... in the JOSE world (vs. in the JSON world) 17:52:16 You can read the base64url definition at https://tools.ietf.org/html/rfc7515#section-2 17:52:25 burn: this does not seem to be going anywhere, not sure how to get futher 17:52:29 ... one thing we could do is seek a broader audience 17:52:32 ... we have done this before 17:52:45 ... where you put up an issue, base58 vs base64url and do a straw poll voting in the issue 17:52:46 q+ to say DID method implementers are already using base58 17:52:50 ... let's the world comment and get to see who has variosu opinions 17:53:01 q? 17:53:03 ... there are arguements that are reasonable in both directions, just which ones do you think are more relevant today 17:53:04 ack dlongley 17:53:04 dlongley, you wanted to say DID method implementers are already using base58 17:53:16 dlongley: DID method implementers ar ealready using base58 for at least two of these key types 17:53:21 ... Tha'ts another piece of information we should take into consideration 17:53:21 q+ to straw poll... just so we have some data... and to worry about getting input from non-implementers. 17:53:26 ... as opposed to having people switch 17:53:52 yancy: base58 is more common in practice in the wild 17:54:02 ... it may not be as well specified as base64 in practice i see it more used 17:54:20 ... 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 17:54:24 ack manu 17:54:24 manu, you wanted to straw poll... just so we have some data... and to worry about getting input from non-implementers. 17:54:30 manu: can we get some data? 17:54:37 ... I have no idea what other pepole are thinking 17:54:46 ... would be good to get that input from the call and move it out to the WG 17:54:52 q+ 17:54:54 ... am concerned about just asking anyone, it should be up to DID implementers 17:55:07 ... 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 17:55:18 q+ 17:55:18 ... it's good to ask the implementers and weigh their feedback more than random people off the internet 17:55:23 ... Can we do a straw poll 17:56:01 JoeAndrieu has joined #did 17:56:07 q- 17:56:15 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) 17:56:21 ack selfissued 17:56:33 selfissued: there's sa process point I feel strongly about - if the implementers are in the WG we should ask them 17:56:39 ... but this is a WG decision not a developer decision 17:56:47 ... all decisions about this spec should be made by WG participants 17:56:52 q+ 17:56:56 ... so asking devs who aren't members of the WG is really not following the w3c process 17:56:58 ack burn 17:57:11 burn: Implementers is what mattres 17:57:15 ... W3C has been clear on that 17:57:28 ... 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 17:57:45 ... however we get data, it does need to be clear whether this is developers, implementers for themselves, implementers representing a larger developer pool, etc 17:57:56 selfissued: sure but for instance in today's job I'm not an implementer but I'm representing dozens of them 17:58:03 q? 17:58:14 ... 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 17:58:20 burn: I don't believe manu was ever suggesting that 17:58:21 manu: correct 17:58:25 ... I was not suggesting that 17:58:36 selfissued: if we're sending a message to w3c-public-did mailing list that's appropriate 17:58:37 manu: yep 17:58:44 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) 17:58:49 ... can we quickly get some data on the straw poll? 17:58:50 +1 base58btc 17:58:54 base64url 17:58:57 +1 base58btc - as an implementer, i would strongly prefer base58 for ed25519, x25519 keys (i would object to base64url for those key types) 17:58:59 +1 base58btc 17:59:15 +1 base58btc 17:59:28 jonathan_holt: it really doesn't matter, in the end 17:59:37 +1 base58btc for ed25519 and x25519, but not sure about base58btc for secp256* keys yet 17:59:37 burn: this is just to collect data 17:59:50 manu: next step is to circulate on the mailing list and get a broader constituency to have an opinion 17:59:57 zakim, close queue 17:59:57 ok, burn, the speaker queue is closed 18:00:05 i'm mostly with markus here 18:00:08 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 18:00:16 burn: thanks everyone, progress! 18:00:25 rrsagent, draft minutes 18:00:25 I have made the request to generate https://www.w3.org/2019/12/04-did-minutes.html burn 18:23:24 gannan has joined #did 18:45:58 gannan has joined #did 20:00:48 Zakim has left #did 20:17:43 gannan has joined #did 22:30:45 gannan has joined #did