<scribe> scribe: ken

Public Key Formats

selfissued: I thought when we last met that to support interoperability we would support JWK as the key format for keys.
... Other key formats would be considered on a case-by-case basis.
... This is not what was written.
... I am disappointed by this outcome.

dlongley: I thought the consensus was that for each key type we would look at each key and select the most popular to recommend.
... There may have been misunderstanding on what the concensus was.

selfissued: The point of standards is to make choices for an international standard.
... Standards involves making choices.
... 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.

<Zakim> Orie_, you wanted to discuss case by case key type formats

selfissued: I hope we can a agree on JWK for all key types; secondarily consider other representations where there is a compelling reason.

Orie: There is progress on what signatures are being used. And libraries.
... If we think in terms of "If a given key type is represented by a JWK, no processor should throw an error."
... If you want something else, that should be ok, too.
... There is some support for PEM. There is some support for others.

<Zakim> mike-lodder, you wanted to discuss why are we mandating key type formats

mike-lodder: I don't see why each method can't choose a format. We shouldn't force everyone to use just one.

<Zakim> dlongley, you wanted to suggest some choices

mike-lodder: I think other formats such as hex or pem are just as interoperable.

dlongley: Interop should be the focus.

<daniel> Am I the only one not hearing anything?

<mike-lodder> agreed dlongley

dlongley: We could consider apps that are trying to understand did docs.

<daniel> Strange, I can hear everyone but dave longley, if he's speaking

<daniel> yes, daniel == danielB

<daniel> I think

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

<daniel> (i guess that'd be strict ===)

dlongley: This could help us avoid multiple representations for each type.
... Representing keys in their native formats could simplify our work.

<Orie_> This discussion is not about things other than public keys (lets not drag ethereum into this) :)

dlongley: It might be better to represent a key in its native format.
... Another argument for not using JWK is that not all libraries adopted a new standard and forced the community to create conversion tools.
... This creates a interop burden.

selfissued: I agree with Orie that we agreed that no processor would err on JWK.
... Dave's points about native formats are good.
... For RSA, ASN.1 would be problematic to convert.

<mike-lodder> Compressed Points vs Uncompressed for ECDSA

selfissued: For elliptic curves the native formats are all binary.
... Every processor of elliptic curves is already capable of conversion between base58 or base64 to binary.
... Library burden is small for the conversion of elliptic curves to JWK.

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.
... Having a universal output format has some benefits.
... I don't know if this is compelling.

<Zakim> Orie_, you wanted to discuss we are not adopting ONE way...

<daniel> In the native Method code, you should be free to use brainfuck or TypedArrays

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.

<daniel> but what are we losing by saying we will output one format?

<manu> daniel - implementation complexity

<manu> daniel - the people that are opposed to that are concerned about implementation complexity

<daniel> So it's more complex to know you're going to get back the same format every time?

<manu> daniel - it's complex to convert when you don't have to today.

<daniel> But why would you ever error on any of them under this direction?

Orie_: Pem could even be the format. There will be methods that have multiple key formats. I prefer JWK.

<daniel> you'd just warn that it is unsupported

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

<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

<gannan_> can someone clarify what we mean by we don't "error"? what is throwing the error? a resolver? a did library? etc.?

<daniel> Does the browser dictate HTML?

<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

<daniel> why don't they use Gopher?

Orie_: I would like to see better interop by saying that no one should err out on a single key format.

manu: There are at least three suggestions.
... The spec will end up with MUST, SHOULD, or MAY.

<dmitriz> +1 to gannan_'s question about clarifying what we mean about throwing an error

<daniel> Why not support Dart in the standard JS engines in browsers?

manu: It the secondary representation a MUST or MAY.

<Orie_> MUST support JWK, MAY support PEM, or vice versa.

manu: selfissued would be happy with MUST be JWK.

<daniel> But you can convert to other formats, no?

manu: Others including mike-lodder and dlongley would not be happy with that.
... From an editor's perspective, the language we would use in unclear.

<manu> https://docs.google.com/spreadsheets/d/12dwUaAruKKpq3a3IfEMEMhpRhI7oM1tQnkmDbW2VGoU/edit

<manu> Survey of existing libs ^

<manu> DID Method implementer survey here: https://forms.gle/Hovf3irBJ5KwgXLQ6

manu: There is a survey of existing libraries and did methods to gather information.
... This will help us determine what is currently in use.
... There are arguments being made without data behind it.
... Some people are fine without the mandate to use JWK. Don't make my life more difficult by mandating JWK.
... There is not a single path to interoperability.

<Zakim> dlongley, you wanted to talk about modern crypto going to simple representations for keys (just encoded bytes)

dlongley: MUST vs SHOULD from a implementors perspective.
... Cryptography is trying to make development simpler by using libraries to make simple methods.

<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

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

<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

dlongley: Can we select a single JWK representation that we have to add, even though we don't have a use for them right now?
... Did methods should not have to deal with the extra complexity that isn't needed for the did method or the application.
... I'm interested to hear what mike-lodder who uses the same ed25519 that we do thinks?

selfissued: mike-lodder said "can't we let the did methods choose their methods?

<mike-lodder> I'm less resistant to mandating ed25519 to base58

<manu> I agree with selfissued here... we don't want the DID Methods defining what key representations they support, that's the other extreme.

selfissued: As new key methods are added we have to keep adding new code.

<dlongley> it may be significantly more difficult to revise DID method code (DLT technology) than application/resolution driver code

selfissued: I thought we agreed to limit the key formats to a finite set.
... All formats MUST be supported.
... Pick a small set that we can agree on.

manu: All MUSTs?

selfissued: Yes.

<daniel> I agree there

<manu> I agree with selfissued here... we did say we'd limit DID Document public key formats.

<daniel> And not only MUST in the spec, but everyone here needs to pick up a shovel and commit to maintaining shared libs

selfissued: If we don't, then the set will grow continually.
... The native formats are all binary for most new key formats.

<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

selfissued: I hope we can agree on the call to define a format which always is supported and then add some other things.

<dlongley> there are two different groups: DID method implementers and DID Doc consumers

selfissued: This is for the benefit of developers.

<daniel> Yeah, none of this should encumber the internal DID Method internal representations

<mike-lodder> from a DLT perspective, JWKs require more bytes,

<manu> Yes, but PEM/DER/ASN.1 is implemented everywhere

<manu> (not for elliptic curve)

<manu> and agree with selfissued there.

<dlongley> agrees that ASN.1/DER is grossly over complicated ... but it is implemented everywhere

selfissued: I could understand choosing pem, but its support for elliptic curves is not mature.

<Orie_> https://w3id.org/security#publicKeyPem

<dlongley> it is implemented for elliptic curve in OpenSSL

<Zakim> Orie_, you wanted to be crytal clear

Orie_: On the question of pem is from my experiencing trying to use the universal resolver.

<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

Orie_: I am not a did method implementor.

<daniel> *lapses

Orie_: I deal with pem and jwk all the time.

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

Orie_: I am asking for each did method MUST support JWK and pem. Or one or the other.

jonathan_holt: I am a proponent of multi formats.
... It is onerous to keep up with all the different representations.

<daniel> Secp256k1 is

<mike-lodder> I don't want to be stuck with JSON as the only format for keys which is what JWKs require

<daniel> it was recently added

jonathan_holt: With JWK you are stuck with the represenrations in the registry.

<Orie_> ... its a good idea to use unregistered crypto in standards? ... shouldn't we register the crypto we use?

<daniel> It was added in direct response to this ecosystem's desire to have it

jonathan_holt: It is behind the times in keeping up with the most recent curves.

selfissued: That registry is extensible by anyone who wants to register the algorithm with a spec.

<mike-lodder> Part of good crypto is also considering constant time operations. I haven't seen a constant time JWK implementation

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.

<mike-lodder> CS is important when designing end user handlers where timing and power attacks are real

daniel: A set of modular libraries that is maintained will be critical.

<mike-lodder> and I doubt I ever will see a JWK CS implementation

<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

manu: What is next? I will continue to gather data regarding did methods to base decisions on.
... I would like to make a few proposals.

<Orie_> +1 for removing options

<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

<kdenhartog> Yeah I'm good for that

<manu> PROPOSAL: Standardize on JWK as the only public key format that MUST be supported.

<mike-lodder> -1

<yancy> -1

<Orie_> -1

<dlongley> -1

-1

<manu> -1

<jonathan_holt> NO

<gannan> -1

<jonathan_holt> -1

<oliver> -1

<selfissued> +1

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

manu: That one will not fly.

<mike-lodder> -1

<dlongley> -1

<yancy> -1

<daniel> +1

<selfissued> -1

<Orie_> +1

<jonathan_holt> -1

-1

<manu> -1

<Orie_> rofl dead

manu: Nope.

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

<selfissued> +1

<Orie_> +1

<daniel> +1

<dmitriz> +1

<mike-lodder> +1

<markus_sabadello> +1

<dlongley> +1 to OR

<yancy> +1

<brent_> +1

<oliver> 0

manu: This means JWK for everything or just BASE58 raw bites encoding

+1

<manu> +0.5

<jonathan_holt> -1

<gannan> +1

<mike-lodder> not just base58

<selfissued> 0

<daniel> lol 0.5, that was funny

manu: OK

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

<selfissued> +1

<Orie_> -1

<dlongley> -1

<mike-lodder> -1

<yancy> -1

-1

manu: You have to support both.

<gannan> -1

manu: THis is too gauge support only.

<manu> -0.5

selfissued: There is a difference between producers and consumers

manu: Yes more polls would be needed.

<Orie_> thanks for that elimination process!

<Zakim> dmitriz, you wanted to talk about limitations of interop.

<dlongley> +1 to there being a difference between producers and consumers and DID methods/applications

dmitriz: All are for interop. Our main audiences are did method developers and app developers.
... Most will use one method or rely on a universal resolver.

<kdenhartog> skip me

dmitriz: The burden is concentrated.

dlon

<kdenhartog> I'll type

<Zakim> dlongley, you wanted to say i have different thoughts about DID Doc consumers to DID method implementers

gley: There is a difference between producers and consumers; we should explore this further.

selfissued: I think there was agreement about having all the key representations in the spec.

<selfissued> PROPOSAL: There will be a small fixed set of key representations for DID documents described in the spec

<selfissued> +1

<manu> +1

<Orie_> +1

<gannan> +1

<dlongley> +1 plus -- you can extend to add more but not for the same key type

<tplooker> +1

<markus_sabadello> +1

<oliver> +1

<mike-lodder> +1

<brent_> +1

+1

<yancy> +1

selfissued: Good

<dlongley> i think my main issue right now is figuring out *which* software MUST support these different key representations is unclear

selfissued: Can manu create a PR to say that there is a fixed set?

manu: I could do it if you will write some concrete text.

<Orie_> great progress, thanks all!

brent_: Thanks all for the progress today.

<Orie_> +1

<mike-lodder> yes

<gannan> +1

<selfissued> +1

+1

<kdenhartog> +1

<tplooker> +1

scribe: Do we need another special call?

<mike-lodder> thanks

scribe: Yes. We'll schedule another call.

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

<dlongley> none of this impacts applications on the consumer side.

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/ASM/ASN.1/
Succeeded: s/manu: -1//
Succeeded: s/yep//
Succeeded: s/dlon//
Present: mike-lodder gannan_ manu ken_ rhiaro selfissued dlongley yancy Orie_ brent_ markus_sabadello oliver_terbu dlehn jonathan_holt
No ScribeNick specified.  Guessing ScribeNick: ken_
Found Scribe: ken

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)