DID WG Public Key Format Discussion — Minutes

Date: 2019-11-25

See also the Agenda and the IRC Log

Attendees

Present: Oliver Terbu, Dave Longley, Michael Lodder, Orie Steele, Yancy Ribbens, Tobias Looker, Manu Sporny, Amy Guy, Brent Zundel

Regrets:

Guests:

Chair:

Scribe(s): Amy Guy

Content:


Michael Lodder: mike-lodder has joined #did

Brent Zundel: there are PRs related to this?

Manu Sporny: that is correct, the PRs were updated

Manu Sporny: https://github.com/w3c/did-core/pulls

Manu Sporny: we were able to get to the point where we could articulate some PRs based on where the discussion currently is
… during the last call we got more feedback from folks and using that feedback I was able to rework the PRs a bit more
… hopefully to bring usc loser to PRs people found acceptable
… I think the call today is to discuss whether or not people feel like we’re at acceptable point or people feel like we need to do more
… to bring people to consensus
… currently there were a couple of missing ones, so I’ll go over the changes really quickly
… I reworked all of the examples, all of the PRs so that they listed the jwk stuff
… and a native format
… you had to support one or the other, but only two choices for every key format
… either jwk or the native key format and that’s it
… I also pulled in some of mike’s suggestions but mike I didn’t see the greated PR that I thought you were going to write, I could have missed that
… The other thing that was added was I believe secp256r1 and curve 25519 stuff, dave said they were missing
… I said I’d write the r1 pr if we seemed to be stabilizing on the other PRs
… So that’s where we are now. On a per key basis there are 2 options, jwk for every one and a native format option for every single one
… you can support one or the other
… Waiting to hear feedback on whether or not that is acceptable
… or push in another direction

Michael Jones: apologies manu I did not get that text written, I went into IETF mode and I’m still not fully emerged
… as far as the PR being written to always list JWK and something else, I thought we had agreement that everything listed must be supported
… if you have an either/or situation you don’t have interop
… I would change all of the PRs to say for all the key formats listed you MUST support them
… Finally Id o think we’re moving in some of the right directions
… rather than piecemeal thing that we support JWK and each of the individual formats, I would like to factor that ?? is always supported and these are other things that are supported

Oliver Terbu: I just want to raise my concern about base58, base64 is an official standard and base58 is also hard to implement and more prone to errors
… there’s confusion around different specs for base58 ?? just want to start the discussion on that

Orie Steele: I know exactly how painful it is to do all those conversions now
… A question I had which came up in some side conversation we have public key, jwk in the current public key objects today and it’s apparently not ?? you would do publickey pem right next to it so you ?? the key object that provided all of these formats for each key

Michael Lodder: please don’t

Orie Steele: that seems sort of complicated and potentially everyone dislikes that idea or not

Michael Lodder: its painful

Orie Steele: just a think that I recently encountered
… want to raise it as a thing that was mentioned somewhere, either gained consensus or that’s terrible let’s definitely make sure that doesn’t get in
… Regarding support for the public key jwk or other formats, if public key jwk is a supported format for all the possible key types ?? totally fine with that
… from my reading of the PRs manu has met my main criteria for jwk. if you choose to support a format that does not support interopability either, people need to ?? represent their keys in at least one standard regardless of key type, sounds like we have that today

Michael Jones: I second oliver’s comments about base58, we’re not doing prototypes any more we’re doing a standard
… standards should reference and use other standards, that or themselves completely defne the meaning of something
… given the only reason for base58 is UI and not for binary key representation I don’t think there’s any reason for us to use it
… e specially given that it seems to be problematic
… I second the base64 as a standard, as is base64-url
… everybody has code for that
… everybody does not have code for a base58, I would delete that entirely

Manu Sporny: I wanted to point out what I implemented as an editor was what we had a resolution on with the strongest support, which was at least one format must be supported, not two
… the stuff in the spec is the thing we strawpolled for last time and the thing that got the number of +1s was you must support jwk or the native format but only one of those two
… the other thing that’s coming up now is the base58 vs base64-url thing
… it seemed like a lot of people wanted to do base58, that came up a lot when we did the base64 encoding
… one of the arguments about the base64 encoding is dids may end up in URLs and you might end up with a load of % encoded stuff
… there are a number of people in the bitcoin and ethereum community that feel like readable public keys are useful
… I’m not going to argue one way or another there, just that there is a contingent of people that feel like base58 is fine
… an implementation of base58 is ?? it’s a super easy thing to implement
… if we need to create a base58 rfc that’s not a difficult thing to do
… I’m not seeing .. It’s basically going to come down to a vote on who wants to do base58 vs base64-url and we’ll have to have some kind of poll on that
… I will note that this is why multibase exists is to enable people to just encode the base encoding format
… I do understand mikes’ agreement against that that’s let’s try to do just one for the entire ecosystem
… The text that exists in the spec is absolutely what the proposed resolution was last time
… and what we had consensus on, jwk or native key format
… an dthen for base58 I think we can, we can debate it but it’s minor, if that’s what we’re down to that’s great because it’s a fairly minor thing
… just a small bit of discussion should lead to us being able to straw poll on that

Manu Sporny: The resolution that had the most support last time: 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.

Manu Sporny: The text that is in the PRs, specifically, this is the resolution that had the most support last time

Dave Longley: Something that I thought we were coming around to was a differentiation between I thought we might be able to get to consensus on consumers of DID document
… more easily than what goes into a DID doc that gets stored on a distributed ledger
… one of the issues with JWK is if we’re going to say a distributed ledger ??? does that mean it has to support every possible profile of a jwk key?
… that’s not possible given GDPR
… one of the reason these simpler formats are chosen for storage on blockchain is for storage but also to avoid the additional fields that could be used or abused to include PII

Brent Zundel: I think storing something is different then presenting something as a did doc

Dave Longley: into a blockchain where a DID doc lives

Manu Sporny: Good point, if we support JWK, are we supporting a subset, or everything and then, what are the GDPR ramifications?

Dave Longley: we’re going to have a hard time saying you must support JWK if you’re storing a DID doc on a ledger or blockchain
… however we might be able to get to consensus in saying you must support JWK if you’re writing a did resolver ?? your application code
… If we need a base58 RFC we can create one, the same way we can extend JWK to add new key formats
… just by getting it doen at IETF, there’s tons of applications that are using that
… Needing an official spec in the form of an RFC is not a barrier
… tons of applications are written using this stuff already
… and already existing did methods that are using keys in that format that are already out there and implemented

Michael Jones: as far as resolutions, we were starting to craft some resolutions at the end of the call and we ran out of time to consider some of the other ones that we should have
… so for instance we never had one which reflected what I believed was the consensus two calls ago that was every key format specified if you’re using that key format you must support to enhance interop
… now support is a funny word, we started to get to this at the end of the last call
… Support may be different for producers and consumers

Dave Longley: yes, “you” and “support” in the sentence “you must support” needs clarification.

Michael Jones: Producers only need to produce one of the supported formats
… but consumers, if you’re gonna have interop, need to be prepared to accept all of the supported formats for that key type
… if we want to do resolutiosn again I would propose we have one that says exactly that

Dave Longley: “producers” and “consumers” might also not be the right terms here – who “produces” the public key? … that’s different from who stores it in a DID registry.

Michael Jones: that producers need only produce one of the supported key formats for a key type but the consumers must be prepared to accept all the supported representations
… The comment about PII in keys is very weird to me

Manu Sporny: kid

Michael Jones: there’s nothing in a JWK that has any PII of any kind

Manu Sporny: jwk.kid

Orie Steele: Regarding PII in DIDDocuments, I think thats out of scope for jwk discussion, its a general problem for all did docs… https://tools.ietf.org/html/rfc7517#section-4

Michael Jones: unless you consider the public key to be PII in and of itself
… it’s json, you could put anything you want in there, but the rest of the did doc is json too

Brent Zundel: GDPR does consider public keys as PII

Brent Zundel: from what I understand

Michael Jones: I agree with manu that if we use base64 in any place it should always be base64-url because it’s then url safe

Manu Sporny: Orie, I don’t think it’s out of scope… we have to consider GDPR concerns w/ all fields.

Michael Jones: Finally I will repeat my hatred of multibase because it’s a choice not to decide
… you have a multiplicity of representations of no reason

Oliver Terbu: to manu’s point, you’re not talking about the encoding for DIDs, the encoding for public key types, so I don’t base64-url is needed, this is because the DID might be visible whereas the public key from the did doc is not even visible to the user, it’s in the JSON

Dave Longley: self-certifying DIDs

Orie Steele: yes, but we can’t prevent people from storing PII in DID Docs… anyone can extend the context and add address / phone number, etc… and as was already noted public keys are PII.

Oliver Terbu: if you decide to use base58 and it’s not an official standard there needs to be a good reason. I haven’t heard a good justification to use base58 over base64, base64 has more implementations

Manu Sporny: I do think that we need to take the GDPR.. the first question is are we supporting the entire JWK spec or a subset of it
… orie said we can’t prevent PII in did docs, we can’t prevent people adding extra things to it but this is a concern for the veres one foundation, we’ve gone to some great lengths to ensur epeople can’t accidentally encode PII into these values
… GDPR is absolutely a concern, this group has to think about it
… folks in the EU do not have the option of avoiding it
… it’s in scope, so we have to ask the question are we supporting the whole jwk spec or a subset of it
… it’s important from a spec writing perspective, we need to know now if we’re subsetting it
… I think mike said he’s eventually going to write some proposals we can consider
… we need to get some proposals down to get feedback
… The ?? base58 question, keep in mind that did-key.. oliver said hey these are public keys we don’t expose them anywhere but in the DID document except for the fact that did-key does
… did-key encodes the public key for ed25519 and secp256k1 encodes the public key in the DID itself
… so just flat out base64 instead of base64-url is problematic
… I agree with mike if we pick base64 it has to be base64-url

Michael Lodder: +1 base64url

Manu Sporny: feel strongly about that

Brent Zundel: s/??/base 64 vs/

Manu Sporny: one of the proposals we’re going to have is the whole base58 vs base64 discussion
… but it feels to me like we’re narrowing down on consensus
… unless mike’s proposals result in greater consensus than what we already have… I don’t want to say this coudl be the last call but that would be great

Oliver Terbu: to manu’s point, I think there’s internal vs external representation of the DID doc
… you could encode the content of the pubkey in the DID itself but how you resolve the DID to a DID doc might be different right?
… you don’t hav eto use the same encoding

Orie Steele: DID Key Spec: https://digitalbazaar.github.io/did-method-key/

Oliver Terbu: the did document could still have base64 and your identifier in the DID could be different

Amy Guy: mike-lodder: I think whether the base58 encoding tends to come from those that have to type it in

Oliver Terbu: there might be some dids where they have to type in the key, maybe it’s a morem anual process
… that’s the whole idea of base58

Dave Longley: +1 yes, let’s choose the more careful encoding (base58)

Oliver Terbu: I’m not against base64, favour that over jwks, but keep in mind that’s why it was invented in the first place
… I know for a fact that’s why bitcoin and some of the others users and consumers of it have it there
… to say that we don’t know any that actually use it, it’s mostly for when it’s visible

Yancy Ribbens: +1 to base58 because of more crypto lib support for encoding pub key

Oliver Terbu: if it’s not visible then fine base64url is fine
… but keep that in mind
… depends on how visible the key is
… if the user is doing something with it directly, read it over the phone or type it in, that’s why base58 was made, to avoid the ambiguity in many of the letters

Manu Sporny: I agree with oliver in that we could encode the value in the DID document as base64 because it’s never going to appear elsewhere and then make a different decision for how we encode the key in the DID key url

Dave Longley: just more complicated to have multiple encodings for self-certifying DIDs and keys

Manu Sporny: but wouldn’t it be nice if we used the same encoding mechanism for both? cos that means you don’t have to do both base64 or base58, just one of them
… I would like us to settle on one base encoding format
… . Also agree strongly with mike-lodder, base64 and base64url existed for quite a long time before base58 came along
… To some folks it sounds ridiculous that you’re going to type one of these keys out
… but I base58 was used for a very specific reason
… it’s if you have that need if you’re able to do that and not mess up a 1 and an l with an O and a 0
… it’s those kinds of mistakes that people want to avoid
… primarily because in some cases people actually do write this information down in offline wallets
… in some cases they are printed on paper
… people store it in their lockboxes
… while it does seem most of us are not going to need that, bitocin specifically absolutely have that in mind

Dave Longley: +1 for choosing based on features of the encoding vs. “it’s in an RFC already”

Manu Sporny: base58 enables that, base64url does not
… the strongest arguments for base58 is that there i a nontrivial subset of the community that finds value in it

Orie Steele: but also lets get an RFC for base58 :)

Manu Sporny: that value is not achievable with base64url, there’s really not a tremendous cost to implement base58 over base64url

Dave Longley: +1 to Orie

Dave Longley: +1 to manu’s comments

Manu Sporny: for those reasons to be as inclusive as possible for how we’re doing the encoding on this I think base58 is a good choice for that

Michael Jones: I took the time to write three proposals to consider to try to move this forward

Michael Jones: Proposed resolution: To promote interop, producers can produce one of the supported key formats for a key type but consumers must accept all supported key formats for the key type

Oliver Terbu: +1 to base58 RFC

Manu Sporny: could you define producer and consumer?

Michael Jones: producer is the one who emits the key representation
… the consumer is the one who reads the key representation and uses it
… the producer in this came woudl be the party producing the DID doc
… the consumer would be the one using the DID doc

Dave Longley: I’m fuzzy on this, I think of the producer as the person or thing that creates the key that gets into a DID doc
… but if by producer you mean the registry that is providing the DID doc then I can get on board with that

Michael Jones: the software that is producing the stream of bytes that is the key representation in the DID doc

Manu Sporny: that doesn’t clarify the question

Michael Jones: he’s using the registry term which isn’t well defined

Dave Longley: I agree with that, but this is also not well defined in a way I’m following

Michael Jones: you’re writing messages, someone writes the message, that’s the producer, the sender
… the consumer is the one who reads the message and parses it and acts on it

Dave Longley: I understand how the terms are typically used

Kyle Den Hartog: I had a confusion around the ambiguity of this as well
… I see the produce and consumer as the same thing in terms of if I’m representing a piece of wallet software I’m interacting with it as both a consumer
… I’m consuming somebody eles’s

Manu Sporny: yes, good point kdenhartog … that’s why producer/consumer is confusing…

Kyle Den Hartog: and also as a resolver or registrar
… on the register side you’re producing only
… in the case of wallet software you may be running both
… I don’t know how much that actually helps in the end user application use cases

Manu Sporny: agree with kdenhartog

Kyle Den Hartog: but it helps in terms of registrar vs resolver

Brent Zundel: A piece of software can be both a producer and a consumer

Michael Jones: I’m rewording this to be unambiguous, 10 seconds
… I’m rewording it in terms of software that produces representation and reads representations

Michael Jones: To promote interop, software that creates a representations of supported key formats for a key type but software that reads a representation of supported key formats for the key type

Amy Guy: ^^

Manu Sporny: rhiaro, that is relevant…

Dave Longley: here’s my confusion - I’m thinking about a piece of client software and a piece of server software in traditional terminology
… a client is submitting a did document where it’s going to be stored
… I consider the client to be the producer and the server to be the consumer
… if we’re submitting DID docs to be registered on a registry then I have a problem with this proposal
… Expecting a registry to be able to accept one or the other type of key format it does not have to accept both

Michael Jones: To promote interoperability, software that creates a representations of supported key formats can choose what representation to use but software that reads a representation of supported key formats for the key type

Michael Jones: I took another stab at wording it

Michael Jones: Proposed resolution: To promote interoperability, software that creates a representations of supported key formats can choose what representation to use but software that reads a representation of supported key formats for the key type must accept all supported key formats for the key type

Dave Longley: this is becoming a distinction without a difference for DID ledgers/registries.

Tobias Looker: could you clarify, the behavior you’re saying dave is say I have a 25519 key and we have two formats a jwk and a base58, the registry needs to support one or the other, and would it have to communicate the format it’s expecting?
… My other q is if the consumer must have the expectation that they can ?? one of those two key formats

Michael Jones: what I’m saying is you should be prepared to accept anything that’s legal to produce
… this spec is defining the spec that’s legal to produce
… if you only accept some of the legal input, you don’t have interoperability

Manu Sporny: mike I think the confusion here is that a did registry (whatever it is, a dlt, the did method implementation) can be viewed as both a producer and a consumer and what that means is that the logic of the proposal you’re putting down is effectively DID ledgers must support both key formats for every single key type
… I think that’s what dlongley is arguing against, IF that is what we’re going to vote on
… however if what we’re saying is a DID ledger is totally cool, it’s okay if it picks either JWK or a native key type, it can make the decision between the two, and then a resolver HAS to be able to convert between jwk to native and native to jwk, this would basically push the implementation burden off from the ledger to the resolver

Dave Longley: +1 to pushing implementation burden to resolver.

Orie Steele: +1 to manu’s statment

Manu Sporny: the question is where are we pushing the implementation burden here, where are you suggesting mike?

Michael Jones: ideally we minimise the implementation burden for everyone by choosing the smallest possible set

Manu Sporny: everyone is already on board with that

Michael Jones: since people appear to want a multiplicity then we have to language about how you achieve interop despite the fact that different software will choose to produce one or the other of the supported formats
… the way you achieve interop is to say that if there’s multiple legal inputs you must be prepared to accept both when you read them
… otherwise you split the world into ?? that does not support one or other representations

Orie Steele: I think I understand what dlongley and manu are saying about the ledger representation of kesy vs the resolver format of keys
… there’s no way that we’re gonna represent keys in any format other than the ones they’ve chosen
… the pratical implications of how you choose to store keys, it sounds like people are willing to talk about ??/ and how it’s relevant to the data model conversation

Dave Longley: +1 to Orie, completely agree

Orie Steele: because the end stage of resolution returns a DID document and that DID document ?? matters to me in terms of interop
… that’s the only thing you’ll directly interop with

Brent Zundel: storing keys doesn’t need to be the same as the presentation of keys in a did doc

Orie Steele: that’s the interface
… sounds like we’ve already agreed that that interface can always support jwk for any key format
… and that interface MAY support base58 or you can make choices that make it hard to talk to you, but you always can choose jwk to talk to more people
… maybe in the future multibase takes off and everyone just opts to use that and we support it theoretically in the future
… the question about where the data model is happen, it happens after the resolver

Brent Zundel: +1 to Orie

Orie Steele: it has no ability to enforce binary representations or what actually gets stored in ledgers

Oliver Terbu: +1 orie

Dave Longley: +1 orie

Orie Steele: i would hope people minimise the representation to the smallest possible on the ledgers ide

Tobias Looker: I’d like to echo what orie was just saying. The DID doc is the product of resolution and the input to registration, rather than the mode of persistence for a given ledger
… The question I was asking before mike was to your position dave, which is if we have these two supported formats in the DID spec itself, are we saying that a ledger would opt to choose one of the two, would not be bound to support both
… which means if you were to ?? a document using a jwk it would throw an error saying I don’t support this format? that was my question

Michael Jones: I’ve got 3 resolutions, we’re trying to clarify one
… Independant of what the software does, if you’ve got a multiplicity of formats hopefully you will emit one when you’re producing a representation, you wouldn’t emit both
… but ot achieve interop you have to be prepared to read both of the supported formats
… that’s what I woudl like to call the question on
… that’s what I tried to put in words

Michael Jones: Proposed resolution: To promote interoperability, software that creates representations of supported key formats can choose what representation to use but software that reads a representation of supported key formats for the key type must accept all supported key formats for the key type

Dave Longley: -1

Michael Jones: I can repost it. But it would seem that’s an obvious thing to do

Manu Sporny: -1 (unclear proposal)

Michael Jones: +1

Orie Steele: -1

Orie Steele: (not clear)

Amy Guy: -1 until producer and consumer are clarified to be the ledger or not

Michael Lodder: -1

Oliver Terbu: -1

Yancy Ribbens: -1

Manu Sporny: let me be concrete on why there’s confusion
… if we take the veres1 ledger as an example, what people are wondering is does the v1 ledger, does it have to support jwk. That means that, v1 is fairily unique in that it akes the did core data model and serializes it directly to the ledger
… if we were to do that, it’s both a producer and a consume rwe could argue, are we saying the ledger itself must encode in jwk?

Michael Jones: whoever encodes gets to choose
… whoever reads the encoding has to be able to accept it

Dave Longley: it is digitally signed and can’t be modified.

Manu Sporny: but the ledger reads the encoding. but I think what you’re actually saying is the resolutio software needs to produce jwk
… it needs to take whatever is in the native format and the resolver itself, I know it’s just a consumer to you mike, but in the community it’s a specific type of consumer

Orie Steele: similar issues arise for sidetree based did methods… the DID Method is responsible for deciding what formats are supported, and they are always a subset of the spec…

Manu Sporny: fi we push the complexity to that specific type of consumer it could get a lot of support

Dave Longley: +1 to Orie

Manu Sporny: if we said producers can produce either jwk or this native format but resolvers specifically MSUT support converting to either format

Michael Jones: if the resolver producing the format or consuming the format?

Manu Sporny: that’s why it’s not clear
… it’s consuming and modifying and producing a new document. It’s translating. It’s not producing or consuming, the resolver is translating

Dave Longley: selfissued: both, consumes from the source and translates to the client of the resolver

Manu Sporny: The resolver would translate form whatever the native ledger format is, which is either jwk or native, and it would trnaslate it into whatever the end consumer is using the resolver to do

Tobias Looker: If the resolver is casting the key format from the ledger to another format then I would say it is a producer?

Brent Zundel: I would say the resolver is translating from the ledger format in order to “produce” the did doc

Manu Sporny: the end consumer can say I would like everything in jwk and the resolver would convert everything in jwk
… or the end consumer says I want everything in native format and the resovler would do that conversion

Oliver Terbu: +1 manu

Manu Sporny: if we do that pushes the implementation burden off the ledgers to the resolvers, which tend to be more complex and capable

Michael Jones: i don’t care what the native on ledger representation is
… that’s private business
… what I care about what the public representations are in the specification

Tobias Looker: I would encourage those to check out markus’ work on the uniresolver last week which has added support to cast public key formats during resolution

Dmitri Zagidulin: I want to echo what manu said about concrete examples
… there’s two times when we’re dealing with concrete DID representations - when we’re writing them to the leger and when we’re reading with a resolver
… When writing to a ledger we can’t request to support all the

Michael Jones: that’s the native format

Dmitri Zagidulin: that’s not the case for all ledgers
… the internal representation is the ledgers’ business. What we’re arguing about is the moment before the internal representation. the API call that accepts the DID for writing

Michael Jones: whoever reads a DID document should be prepared to accept all the supported representations or you don’t have interop
… I’m not sure why this is hard

Dmitri Zagidulin: what about reader and writer instead of producer and consumer?

Michael Jones: the writer can choose what to write, the reader has to accept any valid thing

Dmitri Zagidulin: can we say resolver instead of reader?

Michael Jones: It seems like we can’t get consensus one way or the other becuase it’s not clear ot people so I’d like to move on

Dave Longley: might be helpful - a public representation may be digitally signed and put on a ledger, and the ledger cannot do any transforming of that information at all

Manu Sporny: yes, good point dlongley

Dave Longley: if the ledger is only going to accept one typ eof format the person who signed it and sent it will have to send it in that format or it’ll be rejected by that ledger

Manu Sporny: I totally forgot about that.

Michael Jones: Proposed resolution: Editorially factor the statement that JWK is a supported representation out of the individual key type statements into a general statement

Michael Jones: I’ll try to process that, I think I understand
… next resolution ^

Manu Sporny: +1

Michael Jones: +1

Dave Longley: +1

Michael Jones: refactor JWK part to avoid repeating it

Orie Steele: +1

Michael Lodder: +1

Brent Zundel: +1

Michael Jones: Proposed resolution: Base64url should be supported instead of Base58 if either are supported

Oliver Terbu: +1

Michael Jones: My third one, on another topic ^

Dave Longley: -1

Manu Sporny: -1

Oliver Terbu: +1 (base64)

Michael Jones: +1

Yancy Ribbens: -1

Orie Steele: -1

Michael Lodder: -1

Orie Steele: I want to frame some of these format issues in th econtext of did method implementers vs th eDID spec itself
… a DID method may accept the functionality or only support jwk or any given indiivdiual method ?? like that
… certainly there will be did methods that are incapable of supporting all of the possible representations
… if the DID spec said that was not valid then those methods wouldn’t exist
… my point is the DID method is responsible for performing resolution and creating all the code that connects to the blockchain etc
… the method gets to decide that, and it’s always a subset of what the DID spec allows

Orie Steele: agree

Oliver Terbu: the interface between the ledger and resolver, and the interface between the register and the ledger is out of scope of this spec
… maybe we should add something like that

Dave Longley: I agree with what orie just said and what oliver just said
… We’re working on a data model and syntax
… we’re not going to be able to make statements about consumers, only about what can appear in a DID document, and if you’re trying to represent a key here are the ways you can do it
… I think if we try to have any resolutiosn about producers and consumers people are going to say youc an’t do that, it’s a data model spec
… we’re going to end up with you can represent the key this way or that way and whether or not you accept it is going to be a decision for the systems
… we can make non normative notes about how it should work, but not normative statements

Michael Jones: we could suggest that interop is improved if you support all the formats

Dave Longley: I agree

Brent Zundel: That was a call.
… we will schedule another one of these
… 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
… Tomorrow DID WG call is in the US afternoon/evening time

Amy Guy: RRSAgent please generate minutes