DID WG Topical Call on Keys and Key Formats — Minutes

Date: 2020-08-04

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Manu Sporny, Orie Steele, Markus Sabadello, Dave Longley, Justin Richer, Jonathan Holt, Michael Jones

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Markus Sabadello

Content:

Daniel Burnett: Orie whenever you’re ready, go ahead and start

Orie Steele: Just reviewed https://gist.githubusercontent.com/msporny/2fac3957e84add230ea401259f84e6cd/raw/c72777c1d17ec3e280da77260ffe2f5c40f568f1/gistfile1.txt
… Ready to do a recap
… There is a lot of discussion on the PR to register terms JsonWebKey2020 and JsonWebSignature2020
… I think we’ve covered a number of feelings and worked towards solutions

Daniel Burnett: Orie noted that it is unfortunate that no one from Microsoft is here since much of the discussion is aimed at accommodating concerns they’ve had.

Orie Steele: One feeling is, no private data should go into DID docs
… Another topic is how verification relationships and verification methods relate to each other, and what that means for JSON and RDF
… I feel aligned with manu on this, but other people in the WG may not understand
… Another topic is how much work has to happen in CCG

Daniel Burnett: Mike, we are glad to have you here. Orie is summarizing before we start discussion.

Orie Steele: We seem to agree that JWK are JSON, and that we require spec text around guidance for naming verification methods, and spec text around the difference between verification methods and verification relationships
… It’s hard to summarize this in detail

Manu Sporny: There are multiple ways forward, there may be various additional proposals we may get to today, in order to unblock things
… There are short term things to unblock issues, medium term things to add spec text, and long term topics to discuss security concerns.
… We should decide what we can get done today regarding the PR to make progress
… Should we just vote over each proposal, or first explain each proposal to the grop

Orie Steele: Agree with manu, I think the proposals about warning people should be easy to get approval.

Manu Sporny: +1 to what Orie is proposing.

Orie Steele: E.g. warnings about unstable content, things that may change, maybe we start with those proposals, then spend the rest of the call on the harder issues.

Manu Sporny: Any more explanation needed?

Jonathan Holt: Can you explain it.. This is the verification method properties, or the verification methods types. I have many questions, mainly about appending the year to it. How does this map e.g. to the ed25519 algorithm.
… Some names seem like a novel approach to cryptography. What is behind those names? What do they represent semantically.

Orie Steele: Let’s not talk about what a verification method types means. The “type” attribute is explained in the Linked Data Proofs spec.

Manu Sporny: Based on the discussions of the last weeks, we can agree that all of it is unstable. Based on this we can more easily pull in proposals for now.

Michael Jones: You can change anything in a spec until it’s final. We can take our best stab now and improve later. No need to add warnings.

Orie Steele: selfissued… i agree completely….

Manu Sporny: Certain parts of the spec are not expected to change; there is general expectation of stability. Warnings can be added to those parts that are unstable.

Michael Jones: You can put a generic warning in the introduction, instead of every single section.

Daniel Burnett: I’ve seen this in some groups before. As groups get closer to completion, they tend to add warnings to those parts that are more likely to change. Warnings will be removed in CR.

Manu Sporny: selfissued , I updated the proposal language accordingly

Proposed resolution: Add one issue in the Verification Methods section with a warning stating that there is an ongoing discussion around the naming of verification methods that may impact the final names used in the specification. (Manu Sporny)

Orie Steele: +1

Manu Sporny: +1

Michael Jones: 0

Markus Sabadello: +1

Daniel Burnett: +1

Dave Longley: +1

Jonathan Holt: @dlongley if they are profiles, then why not JSON-Schema

Jonathan Holt: 0

Jonathan Holt: +1

Resolution #1: Add one issue in the Verification Methods section with a warning stating that there is an ongoing discussion around the naming of verification methods that may impact the final names used in the specification.

Manu Sporny: Which proposal should we do next?

Orie Steele: The ones that mention additional warnings. All my proposals except for the first one.
… I would prefer that all these warnings go into the Verification Methods section

Manu Sporny: Do you want me to change proposals to mention this section, or make the decision later?

Orie Steele: Make the decision later
… I agree with manu, but want to describe why we talk about these proposals. The objective is to describe what is not allowed. This will make it clear how we say what is allowed and not allowed.

Dave Longley: I would object to the MUST NOT, but not to a SHOULD NOT

Proposed resolution: DID Core states clearly that private information of any type should not be included in did documents, including but not limited to verification relationships and services. (Manu Sporny)

Manu Sporny: +1

Dave Longley: +1

Orie Steele: +1

Markus Sabadello: +1

Michael Jones: 0

Jonathan Holt: +1

Resolution #2: DID Core states clearly that private information of any type should not be included in did documents, including but not limited to verification relationships and services.

Jonathan Holt: We use fragment to hide sensitive information as evident by the encryption method I presented. Assuming that fragment is not sent to a resolver, it’s supposed to be private.
… The fragment, just like in browsers, should stay local.

Dave Longley: Do we mean fragments that appear in DID documents?

Jonathan Holt: Fragments in a DID URL

Justin Richer: The fragment in the DID URL is NOT sent to a resolver

Dave Longley: a fragment in a DID URL may be part of an identifier for a verification method or service that appears in the DID Document – and in that case, it should not be in the DID Doc per the first proposal

Justin Richer: If the contention is whether this is sent to a resolver, this will never happen, since the input to a resolver is a DID, not a DID URL

Markus Sabadello: The DID Resolution spec in the CCG has some considerations on “client-side dereferencing”: https://w3c-ccg.github.io/did-resolution/#resolver-architectures-client-side

Orie Steele: You shouldn’t publish this information

Proposed resolution: DID Core states that DID URI fragments in a DID Document SHOULD NOT contain private or sensitive information. (Manu Sporny)

Manu Sporny: +1

Orie Steele: +1

Dave Longley: +1

Jonathan Holt: +1

Michael Jones: 0

Markus Sabadello: +1

Daniel Burnett: +1

Resolution #3: DID Core states that DID URI fragments in a DID Document SHOULD NOT contain private or sensitive information.

Manu Sporny: Next one, Orie do you want me to modify this?

Orie Steele: Yes, modify “all key representations in a DID document”

Jonathan Holt: There could be a source of correlation, it can be ambiguous what private/sensitive means

Orie Steele: The raw public key bytes can be used to correlate
… Another motivation here is to not make this about publicKeyJwk vs. publicKeyBase58
… There should be no additional information besides the key itself

Jonathan Holt: I think there are use cases for public DIDs that have ways to find me. E.g. if I’m a physician I may need to publish my public DID. Need to explore more how use cases are affected by this.

Manu Sporny: Ways to contact you would be outside the key, it would be elsewhere in the DID document

Jonathan Holt: That’s fine, like a redirect

Proposed resolution: DID Core warns that all key representations in a DID Document SHOULD NOT contain information that isn’t required to verify a proof. (Manu Sporny)

Manu Sporny: +1

Orie Steele: +1

Michael Jones: 0

Dave Longley: +1

Dave Longley: caveat is that “verify a proof” extends to key agreement protocols as well

Jonathan Holt: +1

Markus Sabadello: +1 agree with dlongley ‘s caveat

Resolution #4: DID Core warns that all key representations in a DID Document SHOULD NOT contain information that isn’t required to verify a proof.

Justin Richer: As that’s worded, it seems like you couldn’t have key identifiers, or any comment information, because you strictly don’t need that. This seems too strict.

Manu Sporny: It’s a SHOULD NOT, so it’s not really preventing people from doing more.

Justin Richer: Yes, but I think this can be better stated as “should only” rather than “should not”, or some other language variation

Orie Steele: i agree as well

Justin Richer: I don’t think it’s a particularly useful normative stance to take.

Dave Longley: perhaps a statement of data minimization principles?

Manu Sporny: Agree with where you are going. Trying to figure out language we can add to that

Dave Longley: information in verification methods SHOULD adhere to data minimization principles

Justin Richer: Maybe phone call is not ideal to work this out.

Manu Sporny: Editors can try to find language that captures this.
… Do you want to attempt a concrete proposal?

Dave Longley: it can be hashed out on the PR

Michael Jones: +1 to Justin’s viewpoint

Justin Richer: +1 to dlongley, this should be getting at sentiments and not text, PR is for text

Orie Steele: In the JOSE spec they describe how you can use encryption to protect access tokens. Because verifiable data registries exist in permanent public places, it may be wise for us to point out shelf life of encryption.

Manu Sporny: We have this in Security Considerations. Do we need to do more?

Proposed resolution: DID Core warns that encryption SHOULD NOT be used to protect sensitive information in DID Document. (Manu Sporny)

Michael Jones: 0

Manu Sporny: +1

Orie Steele: +1

Markus Sabadello: +1

Dave Longley: +1 and we should say because it won’t save you

Jonathan Holt: +1

Resolution #5: DID Core warns that encryption SHOULD NOT be used to protect sensitive information in DID Document.

Jonathan Holt: sorry multitasking

Manu Sporny: Orie which one of the proposals should we do next?

Orie Steele: I think we should do the publicKeyJwk @json type one next

Manu Sporny: There’s a desire to align RFC7517 with JSON-LD.

Proposed resolution: The values associated with publicKeyJwk property MUST be expressed as pure JSON. This is being done to align with the value space of RFC7517. The JSON-LD Context MUST align the value space of publicKeyJwk by specifying “@type”: “@json”. (Manu Sporny)

Manu Sporny: +1

Dave Longley: +1

Orie Steele: +1

Markus Sabadello: +1

Michael Jones: +1

Jonathan Holt: 0, not sure i understand

Resolution #6: The values associated with publicKeyJwk property MUST be expressed as pure JSON. This is being done to align with the value space of RFC7517. The JSON-LD Context MUST align the value space of publicKeyJwk by specifying “@type”: “@json”.

Jonathan Holt: “@type”: “@json”, is this proper JSON-LD?

Manu Sporny: Yes

Orie Steele: Let’s now do separation of concerns between CCG and this WG

Manu Sporny: This is about JSON-LD security, we’re telling CCG to make it more clear. This has created a lot of confusion/discussion. It would be good to be able to point to spec text.

Orie Steele: Pleading with other people to get things done shouldn’t be a reason for us to be blocked
… We should do this, but it shouldn’t be relevant for our progress

Jonathan Holt: I think this has major ramifications for security; we can invite an external export to review this. This is heavy JSON-LD approach.
… We were working on nuances of JSON-LD security, it’s bad if it’s not done properly.

Proposed resolution: The DID WG urges the W3C CCG to write documentation in the Linked Data Security specifications that clarifies how public / private key terminology has been used in the past, why it is vague and leads to security issues (like key reuse attacks in RSA), and why the LDS specs strongly advise specification authors to be more specific about key type and usage when naming key types. (Manu Sporny)

Manu Sporny: +1

Orie Steele: +1

Dave Longley: +1

Markus Sabadello: +1

Orie Steele: the we is not us

Orie Steele: this is pleading

Manu Sporny: jonathan_holt you can raise an issue on the spec for this

Jonathan Holt: 0

Orie Steele: selfissued ?

Michael Jones: Trying to understand what the proposal means

Michael Jones: -1

Justin Richer: -1

Justin Richer: (for the reasons the chair mentioned)

Daniel Burnett: For me this is a decision for the group, not something that goes into text

Manu Sporny: I would be -1 on this, seems like a layer violation
… This would be like us telling the JOSE group what the JWK values should be

Orie Steele: It seems like this is the other side of the other proposal. Can we tell other people that it’s their responsibility, or is it our responsibility
… Both can’t be false. Either we are responsibile, or someone else

Michael Jones: Or guidance is unnecessary

Orie Steele: I wrote the suite, and if I violate the convention, then where is the convention

Manu Sporny: We can’t take responsibility for something that’s not in our charter. LD security is out of scope for this group.

Orie Steele: we might make the same request that JOSE define how kid works with dids…

Manu Sporny: “It’s unnecessary” goes counter to the discussion we’re actively having in the issue… clearly, something needs to be said somewhere.

Michael Jones: There is a third possibility: It’s unnecessary. A lot of this “telling other working groups what to do” is counter-productive. Each WG should do it’s own job. Other groups’s output may be used, or not.

Jonathan Holt: My issue about “cryptographic golem”.. Naming it doesn’t make it appear. It’s a process

Manu Sporny: I want to ask justin_r what his -1 was expressing

Justin Richer: I agree with the chair’s statement that this isn’t text for the spec, but rather a decision for the group.
… It feels weird to me to ask another group to do something
… This shouldn’t be a formal statement, this should be members liaising with other groups

Michael Jones: +1 to active liaison work by people

Justin Richer: My -1 was about making a formal decision related to this

Justin Richer: don’t confuse social engineering with spec engineering

Manu Sporny: How about this proposal: I will write the text

Orie Steele: Do we have to listen to it if you write this in CCG, or selfissued writes it in a JOSE group?

Manu Sporny: Our work uses LD security

Orie Steele: But we’re editors of the DID spec registries, we can decide what gets in
… The authorative control may no longer be in this working group

Justin Richer: This group shouldn’t be making decisions on it

Orie Steele: Agree

Michael Jones: People should coordinate - as Justin suggests

Justin Richer: We should send someone to the other group to discuss with them

Dave Longley: +1 to Justin

Orie Steele: i agree

Manu Sporny: So it’s agreed that this will happen in the CCG (noting that the involved people may be the same)

Orie Steele: PR about JsonWebKey2020 seems blocked

Michael Jones: Please merge the PR :-)

Orie Steele: +1

Manu Sporny: No it’s not blocked, we unblocked it with a proposal

Orie Steele: i love mergin pRs

Manu Sporny: at least we got a bunch of proposals down, ratchets things in.

1. Resolutions