search

w3c-ccg / did-method-key

DID (Decentralized Identifier) did:key method for embedding keys in DID urls
https://w3c-ccg.github.io/did-method-key
Other
19 stars 12 forks source link

Augmentation with DID Parameters #5

Closed OR13 closed 4 years ago

OR13 commented 4 years ago

As discussed here: https://github.com/decentralized-identity/didcomm-messaging/issues/33

One of the uses of matrix parameters is to assist with did method resolution.

In the case of did:key the did document is currently a static text transformation of a public key.

As such the trust model is essentially control over a public key.

If a matrix parameter is included in a did key, and its value is signed by the public key, it should be allowed to be injected into the did document by the did key method resolver.

Things that we might want to inject into a did key:

The logic of how this is applied would need be be careful... I think it should be append only... this is not a solution to revocation issue that occurs with did:key, but it would allow other methods, particularly ones that rely on ledgers or databases to bootstrap connections from a did key and then discard it.

awoie commented 4 years ago

I sympathise with this proposal.

dmitrizagidulin commented 4 years ago

That's interesting... (Although I'm reading 'matrix params' as 'whatever mechanism the WG settles on, likely query params' :) ). I could see how that's useful. (Might also help the BTCR folks.)

OR13 commented 4 years ago

This kind of approach could be used to add publicKeys / services to did:ethr as well :) for free... since did:ethr is similar to did:key in that it is fixed to key material.

dmitrizagidulin commented 4 years ago

@OR13 This discussion is kind of leading me to believe that we need either a general-purpose mechanism on how to do this (across methods), OR (more likely) a separate 'embedded document' DID Method (which can then be used for the 'initial values' usecase).

OR13 commented 4 years ago

I'd rather not create more methods, and instead focus on making did:key stronger if possible... in order to embed document properties, you would need some permanent component, so something like did:key or did:ethr will always be required IMO.

dmitrizagidulin commented 4 years ago

From today's CCG discussion:

Use Cases

Several similar use cases have been brought up, that would benefit from this mechanism:

ChristopherA commented 4 years ago

In the BTCR method, we had not planned to add additional keys or change privileges through matrix parameters, but instead have a mechanism where a DID Extension document was merged into the initial "implicit" DID Document that the blockchain has data for (basically in bitcoin we only have the location of the transaction, a time stamp, a single key, and an option max 80 character location for either a content hash or a URL).

There are at least three ways that a DID Extension document is sourced — either directly through content addressable hash item in the 80 character op_return field, which does not need to be signed as it is in effect "signed" by the blockchain when the implicit key transaction was created, or through a short url (web or not) in the 80 character op_return field, which DOES need to be signed by the implicit key in the transaction. Finally, a signed DID extension document can be presented along with other VCs in a Verifiable Presentation, which provide additional key information for verifiers to validate DIDs referred to inside the Verifiable Presentation.

In the last case, we also had some concepts that these signed DID extension documents themselves might encrypted, and no be decryptable by the verifier without them ALSO holding a cryptographic capability, which could be in the Verifiable Presentation, or may require the verifier to do other operations to complete (for instance, make a payment to a third-party through the Lightning Network).

-- Christopher Allen

OR13 commented 4 years ago

Just a warning about this... there needs to be a deterministic process that does not involve a matrix parameter, that always runs first... and then the method can decide how to apply the parameter...

this leads to an append only like process... you can't remove a property from a did document by adding a signed patch... the attacker can just strip the signed patch and the did will contain the original material again.

OR13 commented 4 years ago

methods would be responsible for considering this kind of thing.

OR13 commented 4 years ago

Regarding encryption, you could use this method to inject a different key agreement key into the same did document, so that each party you invited to communicate would use a different key... especially useful for did:ethr or other ledger based methods that lack some of the privacy features of did:peer.

OR13 commented 4 years ago

If you revoke (remove) the key used to sign the patch, the patch would not be applied (if the method implementer is honest).

dmitrizagidulin commented 4 years ago

Open Questions

Since there seems to be interest in this functionality, here are some questions that we'd need to answer.

  1. Is this a good idea at all? What is the threat model to having this capability, and can those be sufficiently mitigated?
  2. Matrix parameters, query parameters, or some other mechanism (such as Hashlink)? (This will be determined by the DID WG discussion at https://github.com/w3c/did-core/issues/159.)
  3. Should this be a method-specific mechanism, a top-level DID Core mechanism, or perhaps a separate Best Practices note, "Here is how you securely and deterministically augment your DID Document via the URL" or something.
  4. What format should the augmentations take? A list of parameters, a signed JSON Patch, an entire embedded DID Document?
  5. Mechanism for establishing the integrity of the augmentation (how do we sign it?) - JSON-LD + LDProof + base58 encoding, or use a JOSE-based VP, etc?
csuwildcat commented 4 years ago

Open Questions

Since there seems to be interest in this functionality, here are some questions that we'd need to answer.

  1. Is this a good idea at all? What is the threat model to having this capability, and can those be sufficiently mitigated?

If you are assuming initial-values, the threat model would depend on what the particular Method uses for its initial-values. For Sidetree-based DIDs, the hash of the initial-values itself is a part of the DID identifier suffix, so it's hard-bound to the DID and tampering is not possible. Not sure how other methods would use it, but there are several secure constructions possible.

  1. Matrix parameters, query parameters, or some other mechanism? (This will be determined by the DID WG discussion.)

Yeah, I really had hoped folks could close this out faster. I will be pushing hard for resolution from our side.

  1. Should this be a method-specific mechanism, a top-level DID Core mechanism, or perhaps a separate Best Practices note, "Here is how you securely and deterministically augment your DID Document via the URL" or something.

IMO, it should be a Generic Matrix parameter, because it is intended to do exactly the same thing regardless of the DID Method that implements support. Drummond brought up the fact that other Generic params behave the same way - they may use different values for the param, but the intent and outcome is unified across them all.

  1. What format should the augmentations take? A list of parameters, a signed JSON Patch, an entire embedded DID Document?

I would not constrain the format so tightly, because that starts imposing a lot of opinions on Methods. Sidetree uses an object with various values, one of which is DID Doc-centric data, but there are other included values that aren't. I would try to treat the value shape itself as Method-defined.

ChristopherA commented 4 years ago

Though I'm not quite sure about DID augmentation through matrix parameters yet, the concept no matter the transport (via unsigned but provable via content addressable on a blockchain, or signed via matrix parameter, op_return, additional data inside a verifiable presentation, or after decryption by the verifier using a cryptographic capability) we should consider developing together a common approach across methods. Our specification of a data format for augmenting a DID document could ultimately be considered as a possible future DID-WG note.

-- Christopher Allen

OR13 commented 4 years ago

@ChristopherA sorta related... my github repo (based off yours) has both material for did web and did btrc... https://github.com/OR13/self

It would be cool is we could standardize these remote extensions in a way where a single file could be used for both, or where they were structured similarly...

As you noted we have:

The trust and security models for these are different, but I think each has its place.

OR13 commented 4 years ago

@dlongley @msporny any comments on this: https://dhh1128.github.io/peer-did-method-spec/index.html#generation-method

If the intention is to not support any did parameters in did:key, I can close this issue, and try and get did:peer to standardize a parameter based patch system on top of did:key.... another approach would be to bind to a specific did key resolver which injected service endpoints.

msporny commented 4 years ago

If the intention is to not support any did parameters in did:key

I don't think there is currently any intention to support DID Parameters in did:key, based on what's in the DID Core spec right now. Specifically,

This doesn't mean that there might be DID Parameters that might make sense for did:key in the future, but at present, there are no DID Parameters in the DID Core spec that apply to did:key.

There might be an argument to pull DID Parameters from did:peer into did:key, but if so, that more specific request (naming the DID Parameter) should be raised in another issue.

OR13 commented 4 years ago

Closing, reason: no planned support for did parameters.