19:02:17 <RRSAgent> RRSAgent has joined #did
19:02:17 <RRSAgent> logging to https://www.w3.org/2019/11/13-did-irc
19:02:19 <ken_> ken_ has joined #did
19:02:20 <Zakim> Zakim has joined #did
19:02:23 <mike-lodder> present+
19:02:27 <manu> rrsagent, make logs public
19:02:29 <gannan_> present+
19:02:31 <manu> present+
19:02:34 <ken_> present+
19:03:03 <selfissued> selfissued has joined #did
19:03:04 <rhiaro> present+
19:03:10 <selfissued> present+
19:03:22 <dlongley> present+
19:03:39 <manu> Meeting: DID WG Public Key Discussion
19:03:43 <ken_> scribe: ken
19:03:43 <yancy> present+
19:03:55 <tplooker> tplooker has joined #did
19:03:59 <ken_> Topic: Public Key Formats
19:04:03 <selfissued> q+
19:04:25 <brent_> ack selfissued
19:04:33 <Orie_> Orie_ has joined #did
19:04:42 <Orie_> present+
19:05:18 <brent_> present +
19:05:20 <brent_> present+
19:05:39 <markus_sabadello> present+
19:05:54 <ken_> selfissued: I thought when we last met that to support interoperability we would support JWK as the key format for keys.
19:06:20 <ken_> ... Other key formats would be considered on a case-by-case basis.
19:06:32 <ken_> ... This is not what was written.
19:06:36 <brent_> q?
19:06:44 <dlongley> q+
19:06:45 <ken_> ... I am disappointed by this outcome.
19:06:54 <brent_> ack dlongley
19:07:06 <selfissued> q+
19:07:18 <Orie_> q+ to discuss case by case key type formats
19:07:31 <ken_> dlongley: I thought the consensus was that for each key type we would look at each key and select the most popular to recommend.
19:07:32 <mike-lodder> q+ to discuss why are we mandating key type formats
19:07:48 <brent_> ack selfissued
19:07:59 <ken_> ... There may have been misunderstanding on what the concensus was.
19:08:08 <dlongley> q+ to suggest some choices
19:08:23 <ken_> selfissued: The point of standards is to make choices for an international standard.
19:08:44 <ken_> ... Standards involves making choices.
19:09:28 <ken_> ... In my mind, the reason we were willing to allow a single non-json encoding is that we would have a standard for the json encoding.
19:09:32 <brent_> q?
19:10:06 <brent_> ack Orie_
19:10:06 <Zakim> Orie_, you wanted to discuss case by case key type formats
19:10:11 <ken_> ... I hope we can a agree on JWK for all key types; secondarily consider other representations where there is a compelling reason.
19:10:14 <oliver> oliver has joined #did
19:10:18 <oliver> present+ oliver_terbu
19:10:33 <ken_> Orie: There is progress on what signatures are being used. And libraries.
19:10:57 <selfissued> q+
19:11:08 <ken_> ... If we think in terms of "If a given key type is represented by a JWK, no processor should throw an error."
19:11:21 <ken_> ... If you want something else, that should be ok, too.
19:11:38 <brent_> q+ danielB
19:11:45 <manu> q+ to note that "secondarily on a case by case basis" is new, at least as far as I know... and I'm hearing new positions on the call. What Orie is saying is different from what Mike is saying is different from what Dave is saying.
19:11:46 <dlehn> present+
19:11:48 <daniel> daniel has joined #did
19:11:48 <ken_> ... There is some support for PEM. There is some support for others.
19:11:53 <daniel> q+
19:11:56 <brent_> ack mike-lodder
19:11:56 <Zakim> mike-lodder, you wanted to discuss why are we mandating key type formats
19:12:46 <ken_> mike-lodder: I don't see why each method can't choose a format. We shouldn't force everyone to use just one.
19:13:04 <manu> q- later
19:13:15 <brent_> ack dlongley
19:13:15 <Zakim> dlongley, you wanted to suggest some choices
19:13:18 <ken_> ... I think other formats such as hex or pem are just as interoperable.
19:13:32 <ken_> dlongley: Interop should be the focus.
19:14:02 <daniel> Am I the only one not hearing anything?
19:14:09 <mike-lodder> agreed dlongley
19:14:12 <ken_> ... We could consider apps that are trying to understand did docs.
19:14:57 <daniel> Strange, I can hear everyone but dave longley, if he's speaking
19:15:04 <daniel> yes, daniel == danielB
19:15:06 <daniel> I think
19:15:16 <ken_> ... I agree it makes sense to pick something for apps. Picking JWK might not be the best choice. We need to see how peoople are using the key types.
19:15:18 <daniel> (i guess that'd be strict ===)
19:15:18 <manu> q- danielB
19:15:38 <ken_> ... This could help us avoid multiple representations for each type.
19:15:54 <manu> q+ to note information gathering exercise.
19:16:05 <ken_> ... Representing keys in their native formats could simplify our work.
19:16:12 <brent_> q?
19:16:30 <Orie_> This discussion is not about things other than public keys (lets not drag ethereum into this) :)
19:16:40 <ken_> ... It might be better to represent a key in its native format.
19:17:55 <ken_> ... Another argument for not using JWK is that not all libraries adopted a new standard and forced the community to create conversion tools.
19:18:23 <ken_> ... This creates a interop burden.
19:18:34 <brent_> ack selfissued
19:18:46 <Orie_> q+ to discuss we are not adopting ONE way...
19:18:57 <manu> q- later
19:18:58 <ken_> selfissued: I agree with Orie that we agreed that no processor would err on JWK.
19:19:13 <ken_> ... Dave's points about native formats are good.
19:19:43 <ken_> ... For RSA, ASM would be problematic to convert.
19:19:50 <manu> s/ASM/ASN.1/
19:20:01 <mike-lodder> Compressed Points vs Uncompressed for ECDSA
19:20:01 <dlongley> q+ to talk about modern crypto going to simple representations for keys (just encoded bytes)
19:20:02 <ken_> ... For elliptic curves the native formats are all binary.
19:20:03 <gannan> gannan has joined #did
19:21:01 <ken_> ... Every processor of elliptic curves is already capable of conversion between base58 or base64 to binary.
19:21:07 <brent_> q?
19:21:43 <jonathan_holt> present+ jonathan_holt
19:22:54 <ken_> ... Library burden is small for the conversion of elliptic curves to JWK.
19:22:55 <brent_> ack daniel
19:23:43 <selfissued> q+
19:23:57 <ken_> daniel: I think that most methods under the covers could be using CBOR or other formats. On output can be in any format or representation.
19:24:20 <ken_> ... Having a universal output format has some benefits.
19:24:30 <ken_> ... I don't know if this is compelling.
19:24:59 <brent_> q?
19:25:19 <brent_> ack Orie_
19:25:19 <Zakim> Orie_, you wanted to discuss we are not adopting ONE way...
19:25:56 <daniel> In the native Method code, you should be free to use brainfuck or TypedArrays
19:26:07 <ken_> Orie_: I think we have an opportunity to decide on a representation that will not cause errors. This does not preclude using other methods in your method.
19:26:11 <daniel> but what are we losing by saying we will output one format?
19:26:26 <manu> daniel - implementation complexity
19:26:32 <kdenhartog> kdenhartog has joined #did
19:26:39 <manu> daniel - the people that are opposed to that are concerned about implementation complexity
19:26:46 <brent_> q?
19:26:46 <daniel> So it's more complex to know you're going to get back the same format every time?
19:27:09 <manu> daniel - it's complex to convert when you don't have to today.
19:27:22 <daniel> But why would you ever error on any of them under this direction?
19:27:28 <ken_> ... Pem could even be the format. There will be methods that have multiple key formats. I prefer JWK.
19:27:31 <daniel> you'd just warn that it is unsupported
19:27:42 <dmitriz> daniel: I think the main argument is the ol' federalist vs state rights argument :) Does the core DID spec dictate a single key type, or do individual DID methods dictate a key type for themselves.
19:27:46 <manu> daniel - for example, if you use PEM today ... zero conversion going to/from openssl ... but if it's JWK, then you have to go to/from that format to PEM
19:27:56 <gannan_> can someone clarify what we mean by we don't "error"? what is throwing the error? a resolver? a did library? etc.?
19:27:57 <daniel> Does the browser dictate HTML?
19:28:10 <brent_> ack manu
19:28:10 <Zakim> manu, you wanted to note that "secondarily on a case by case basis" is new, at least as far as I know... and I'm hearing new positions on the call. What Orie is saying is different
19:28:11 <daniel> why don't they use Gopher?
19:28:13 <Zakim> ... from what Mike is saying is different from what Dave is saying. and to note information gathering exercise.
19:28:19 <ken_> ... I would like to see better interop by saying that no one should err out on a single key format.
19:28:36 <ken_> manu: There are at least three suggestions.
19:29:04 <ken_> ... The spec will end up with MUST, SHOULD, or MAY.
19:29:09 <dmitriz> +1 to gannan_'s question about clarifying what we mean about throwing an error
19:29:12 <daniel> Why not support Dart in the standard JS engines in browsers?
19:29:30 <ken_> ... It the secondary representation a MUST or MAY.
19:29:54 <Orie_> MUST support JWK, MAY support PEM, or vice versa.
19:30:15 <ken_> ... selfissued would be happy with MUST be JWK.
19:30:25 <daniel> But you can convert to other formats, no?
19:30:34 <ken_> ... Others including mike-lodder and dlongley would not be happy with that.
19:30:52 <Orie_> q+ to be crytal clear
19:31:02 <ken_> ... From an editor's perspective, the language we would use in unclear.
19:31:08 <manu> https://docs.google.com/spreadsheets/d/12dwUaAruKKpq3a3IfEMEMhpRhI7oM1tQnkmDbW2VGoU/edit
19:31:14 <manu> Survey of existing libs ^
19:31:26 <manu> DID Method implementer survey here: https://forms.gle/Hovf3irBJ5KwgXLQ6
19:31:37 <ken_> ... There is a survey of existing libraries and did methods to gather information.
19:32:09 <ken_> ... This will help us determine what is currently in use.
19:32:48 <ken_> ... There are arguments being made without data behind it.
19:33:30 <ken_> ... Some people are fine without the mandate to use JWK. Don't make my life more difficult by mandating JWK.
19:34:04 <ken_> ... There is not a single path to interoperability.
19:34:11 <brent_> ack dlongley
19:34:11 <Zakim> dlongley, you wanted to talk about modern crypto going to simple representations for keys (just encoded bytes)
19:34:33 <ken_> dlongley: MUST vs SHOULD from a implementors perspective.
19:35:07 <ken_> ... Cryptography is trying to make development simpler by using libraries to make simple methods.
19:35:49 <daniel> If multiple formats are allowed, I think we MUST have everyone who implements using a format/type commit to a common lib that encompasses every one in common usage, and they all swear to commit the resources necessary to maintain that lib in perpetuity
19:36:07 <jonathan_holt> q+
19:36:08 <ken_> ... If we just use ed25519, I would prefer a single representation. If we have to add JWK support to our node software, it will require additional work.
19:36:39 <daniel> That lib can depend on other modules, but we better have a simple, single lib that works in the most common envs that we track, update, maintain, and strongly protect
19:36:53 <ken_> ... Can we select a single JWK representation that we have to add, even though we don't have a use for them right now?
19:37:26 <ken_> ... Did methods should not have to deal with the extra complexity that isn't needed for the did method or the application.
19:37:33 <manu> q+ to talk about the process around how we're going to make this decision.... gather data, analyze it, apply it to arguments, ranked choice straw poll.
19:37:45 <manu> q+ to put some easy proposals in to get feedback.
19:37:50 <daniel> q+
19:37:58 <manu> q- later
19:38:04 <brent_> ack selfissued
19:38:07 <ken_> ... I'm interested to hear what mike-lodder who uses the same ed25519 that we do thinks?
19:38:33 <ken_> selfissued: mike-lodder said "can't we let the did methods choose their methods?
19:38:45 <mike-lodder> I'm less resistant to mandating ed25519 to base58
19:38:47 <dmitriz> q+ to talk about limitations of interop.
19:38:51 <manu> I agree with selfissued here... we don't want the DID Methods defining what key representations they support, that's the other extreme.
19:39:03 <kdenhartog> q+
19:39:03 <ken_> ... As new key methods are added we have to keep adding new code.
19:39:22 <dlongley> it may be significantly more difficult to revise DID method code (DLT technology) than application/resolution driver code
19:39:25 <ken_> ... I thought we agreed to limit the key formats to a finite set.
19:39:38 <ken_> ... All formats MUST be supported.
19:39:59 <ken_> ... Pick a small set that we can agree on.
19:40:07 <ken_> manu: All MUSTs?
19:40:11 <ken_> selfissued: Yes.
19:40:15 <daniel> I agree there
19:40:19 <manu> I agree with selfissued here... we did say we'd limit DID Document public key formats.
19:40:45 <daniel> And not only MUST in the spec, but everyone here needs to pick up a shovel and commit to maintaining shared libs
19:40:47 <ken_> selfissued: If we don't, then the set will grow continually.
19:41:20 <ken_> ... The native formats are all binary for most new key formats.
19:41:29 <daniel> Should be a repo somewhere like DIF where we can aggressively maintain the lib to ensure devs have an option for use across common envs
19:41:56 <ken_> ... I hope we can agree on the call to define a format which always is supported and then add some other things.
19:42:09 <dlongley> there are two different groups: DID method implementers and DID Doc consumers
19:42:12 <ken_> ... This is for the benefit of developers.
19:42:14 <dlongley> q?
19:42:30 <dlongley> q+ to say i have different thoughts about DID Doc consumers to DID method implementers
19:42:34 <daniel> Yeah, none of this should encumber the internal DID Method internal representations
19:42:38 <mike-lodder> from a DLT perspective, JWKs require more bytes,
19:42:38 <manu> Yes, but PEM/DER/ASN.1 is implemented everywhere
19:42:44 <manu> (not for elliptic curve)
19:42:50 <manu> and agree with selfissued there.
19:42:50 <dlongley> agrees that ASN.1/DER is grossly over complicated ... but it is implemented everywhere
19:42:53 <ken_> ... I could understand choosing pem, but its support for elliptic curves is not mature.
19:43:09 <selfissued> q+
19:43:11 <brent_> q?
19:43:15 <Orie_> https://w3id.org/security#publicKeyPem
19:43:21 <dlongley> it is implemented for elliptic curve in OpenSSL
19:43:22 <brent_> ack Orie_
19:43:22 <Zakim> Orie_, you wanted to be crytal clear
19:44:01 <ken_> Orie_: On the question of pem is from my experiencing trying to use the universal resolver.
19:44:14 <daniel> Hell, i'd even like to see a spreadsheet with names of DID Method maintainers and what types they are introducing in the world, with an email, telephone numbers, and other ways to contact them if their support in the shared library lapsts
19:44:14 <ken_> ... I am not a did method implementor.
19:44:20 <daniel> *lapses
19:44:53 <ken_> ... I deal with pem and jwk all the time.
19:45:05 <brent_> q?
19:45:20 <daniel> I want to call someone and say "Buddy, pal, you wanted to use ASNPEMDAS v12.3.54564, so you need to get your module in this lib updated NOW, because your DIDs are circulating everywhere"
19:45:22 <ken_> ... I am asking for each did method MUST support JWK and pem. Or one or the other.
19:45:33 <brent_> ack jonathan_holt
19:45:40 <ken_> jonathan_holt: I am a proponent of multi formats.
19:46:02 <ken_> ... It is onerous to keep up with all the different representations.
19:46:22 <daniel> Secp256k1 is
19:46:25 <mike-lodder> I don't want to be stuck with JSON as the only format for keys which is what JWKs require
19:46:26 <daniel> it was recently added
19:46:27 <ken_> ... With JWK you are stuck with the represenrations in the registry.
19:46:45 <brent_> q?
19:46:46 <Orie_> ... its a good idea to use unregistered crypto in standards? ... shouldn't we register the crypto we use?
19:46:49 <daniel> It was added in direct response to this ecosystem's desire to have it
19:46:53 <ken_> ... It is behind the times in keeping up with the most recent curves.
19:47:36 <ken_> selfissued: That registry is extensible by anyone who wants to register the algorithm with a spec.
19:47:45 <brent_> ack daniel
19:49:01 <mike-lodder> Part of good crypto is also considering constant time operations. I haven't seen a constant time JWK implementation
19:49:05 <ken_> daniel: If the decision is made to select more than one format, I think it is not in the best of the world because it can cause failures.
19:49:25 <mike-lodder> CS is important when designing end user handlers where timing and power attacks are real
19:49:43 <ken_> ... A set of modular libraries that is maintained will be critical.
19:49:46 <mike-lodder> and I doubt I ever will see a JWK CS implementation
19:49:58 <brent_> ack manu
19:49:58 <Zakim> manu, you wanted to talk about the process around how we're going to make this decision.... gather data, analyze it, apply it to arguments, ranked choice straw poll. and to put
19:50:01 <Zakim> ... some easy proposals in to get feedback.
19:50:30 <ken_> manu: What is next? I will continue to gather data regarding did methods to base decisions on.
19:50:55 <ken_> ... I would like to make a few proposals.
19:50:59 <Orie_> +1 for removing options
19:51:09 <mike-lodder> I would like to see a fixed set of encodings that are allowed like a key MUST be encoded in one of the following
19:51:30 <kdenhartog> Yeah I'm good for that
19:51:43 <manu> PROPOSAL: Standardize on JWK as the only public key format that MUST be supported.
19:51:50 <mike-lodder> -1
19:51:51 <yancy> -1
19:51:51 <Orie_> -1
19:51:52 <dlongley> -1
19:51:52 <ken_> -1
19:51:53 <manu> -1
19:51:54 <jonathan_holt> NO
19:51:54 <gannan> -1
19:51:57 <jonathan_holt> -1
19:51:59 <oliver> -1
19:52:01 <selfissued> +1
19:52:10 <manu> PROPOSAL: Standardize on JWK and PEM as the only two supported key formats for at least RSA, secp256k1, secp256r1, ed25519, Curve25519. At least ONE format MUST be supported.
19:52:16 <ken_> manu: That one will not fly.
19:52:23 <mike-lodder> -1
19:52:24 <dlongley> -1
19:52:24 <yancy> -1
19:52:24 <daniel> +1
19:52:26 <selfissued> -1
19:52:27 <Orie_> +1
19:52:27 <jonathan_holt> -1
19:52:28 <ken_> -1
19:52:33 <manu> -1
19:52:35 <Orie_> rofl dead
19:52:44 <ken_> manu: Nope.
19:52:45 <dmitriz> dmitriz has joined #did
19:52:47 <manu> PROPOSAL: Standardize on JWK (FormatA) and a per key type format as the only two supported key formats for at least RSA, secp256k1, secp256r1, ed25519, Curve25519. At least ONE format MUST be supported.
19:53:07 <selfissued> +1
19:53:16 <dmitriz> dmitriz has joined #did
19:53:18 <Orie_> +1
19:53:19 <daniel> +1
19:53:20 <dmitriz> +1
19:53:21 <mike-lodder> +1
19:53:22 <markus_sabadello> +1
19:53:24 <dlongley> +1 to OR
19:53:24 <yancy> +1
19:53:26 <brent_> +1
19:53:27 <oliver> 0
19:53:30 <ken_> manu: This means JWK for everything or just BASE58 raw bites encoding
19:53:32 <ken_> +1
19:53:34 <manu> +0.5
19:53:36 <jonathan_holt> -1
19:53:40 <gannan> +1
19:53:40 <mike-lodder> not just base58
19:53:40 <selfissued> 0
19:53:41 <daniel> lol 0.5, that was funny
19:53:42 <ken_> manu:OK
19:53:46 <manu> PROPOSAL: Standardize on JWK (FormatA) and a per key type format as the only two supported key formats for at least RSA, secp256k1, secp256r1, ed25519, Curve25519. At least TWO formats MUST be supported.
19:53:57 <selfissued> +1
19:53:57 <Orie_> -1
19:53:59 <dlongley> -1
19:53:59 <mike-lodder> -1
19:54:00 <yancy> -1
19:54:01 <ken_> manu: -1
19:54:14 <ken_> s/manu: -1//
19:54:17 <ken_> -1
19:54:34 <ken_> manu: You have to support both.
19:54:44 <gannan> -1
19:54:58 <ken_> ... THis is too gauge support only.
19:55:00 <manu> -0.5
19:55:24 <ken_> selfissued: There is a difference between producers and consumers
19:55:34 <brent_> q?
19:55:34 <ken_> manu: Yes more polls would be needed.
19:55:38 <Orie_> thanks for that elimination process!
19:55:54 <brent_> ack dmitriz
19:55:54 <Zakim> dmitriz, you wanted to talk about limitations of interop.
19:55:59 <dlongley> +1 to there being a difference between producers and consumers and DID methods/applications
19:56:34 <ken_> dmitriz: All are for interop. Our main audiences are did method developers and app developers.
19:56:48 <brent_> ack kdenhartog
19:56:53 <ken_> ... Most will use one method or rely on a universal resolver.
19:57:02 <kdenhartog> skip me
19:57:05 <ken_> ... The burden is concentrated.
19:57:08 <ken_> dlon
19:57:08 <kdenhartog> I'll type
19:57:09 <brent_> ack dlongley
19:57:09 <Zakim> dlongley, you wanted to say i have different thoughts about DID Doc consumers to DID method implementers
19:57:43 <ken_> dlongley:  There is a difference between producers and consumers; we should explore this further.
19:58:04 <manu> yep
19:58:07 <manu> s/yep//
19:58:13 <ken_> selfissued: I think there was agreement about having all the key representations in the spec.
19:58:16 <manu> s/dlon//
19:58:19 <selfissued> PROPOSAL: There will be a small fixed set of key representations for DID documents described in the spec
19:58:20 <manu> rrsagent, draft minutes
19:58:20 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/13-did-minutes.html manu
19:58:25 <selfissued> +1
19:58:27 <manu> +1
19:58:28 <Orie_> +1
19:58:33 <gannan> +1
19:58:35 <dlongley> +1 plus -- you can extend to add more but not for the same key type
19:58:35 <tplooker> +1
19:58:35 <markus_sabadello> +1
19:58:36 <oliver> +1
19:58:38 <mike-lodder> +1
19:58:42 <brent_> +1
19:58:42 <ken_> +1
19:58:44 <yancy> +1
19:59:01 <ken_> selfissued: Good
19:59:25 <dlongley> i think my main issue right now is figuring out *which* software MUST support these different key representations is unclear
19:59:29 <ken_> ... Can manu create a PR to say that there is a fixed set?
19:59:55 <ken_> manu: I could do it if you will write some concrete text.
20:00:04 <Orie_> great progress, thanks all!
20:00:09 <ken_> brent_: Thanks all for the progress today.
20:00:15 <Orie_> +1
20:00:15 <mike-lodder> yes
20:00:15 <gannan> +1
20:00:16 <selfissued> +1
20:00:18 <ken_> +1
20:00:19 <kdenhartog> +1
20:00:20 <tplooker> +1
20:00:30 <ken_> ... Do we need another special call?
20:00:43 <mike-lodder> thanks
20:00:44 <ken_> ... Yes. We'll schedule another call.
20:00:46 <manu> rrsagent, draft minutes
20:00:46 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/13-did-minutes.html manu
20:01:16 <ken_> ken_ has left #did
20:02:06 <manu> Chair: Brent
20:02:27 <manu> rrsagent, draft minutes
20:02:27 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/13-did-minutes.html manu
20:02:30 <manu> rrsagent, publish minutes
20:02:30 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/13-did-minutes.html manu
20:08:27 <dlongley> another important point to consider ... JWK has a number of places that would allow someone to sneak in PII -- which is a problem for DID methods that use blockchain tech... so DID method software/validators that accept JWK may have to reject *some* JWKs and not others.
20:09:14 <dlongley> none of this impacts applications on the consumer side.
20:16:31 <manu> rrsagent, publish minutes
20:16:31 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/13-did-minutes.html manu
20:47:45 <dmitriz> dmitriz has joined #did
20:58:18 <dmitriz> dmitriz has joined #did