w3c-ccg / did-method-v1 Goto Github PK

It would be very helpful (in terms of key add/remove/rotate operations), if we added ids to the authentication/authorization suites in the spec. (That way, they can be addressed individually, as opposed to their index in the array of suites.)

So, currently:

{
  "@context": "https://w3id.org/veres-one/v1",
  "id": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ",
  ...
  "grantCapability": [{
    "type": "Ed25519SignatureCapabilityAuthorization2018",
    "publicKey": {
      "id": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ#ocap-grant-key-1",
      "type": "Ed25519VerificationKey2018",
      "owner": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ",
      "publicKeyBase58": "HURvcFiZbmtaQQMhkVVoq1JpxxRe8UrBS5wBQMJhXkfM"
    }
  }],
  "invokeCapability": [{
    "type": "Ed25519SignatureCapabilityAuthorization2018",
    "publicKey": {
      "id": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ#ocap-invoke-key-1",
      "type": "Ed25519VerificationKey2018",
      "owner": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ",
      "publicKeyBase58": "Gu5yfYsbYvmSeSsAbBBNafy9i6G3o5kiX5PxUGPg1iFJ"
    }
  }]
}

Proposed:

{
  "@context": "https://w3id.org/veres-one/v1",
  "id": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ",
  ...
  "grantCapability": [{
    "id": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ#grant-suite-1",
    "type": "Ed25519SignatureCapabilityAuthorization2018",
    "publicKey": {
      "id": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ#ocap-grant-key-1",
      "type": "Ed25519VerificationKey2018",
      "owner": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ",
      "publicKeyBase58": "HURvcFiZbmtaQQMhkVVoq1JpxxRe8UrBS5wBQMJhXkfM"
    }
  }],
  "invokeCapability": [{
    "id": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ#invoke-suite-1",
    "type": "Ed25519SignatureCapabilityAuthorization2018",
    "publicKey": {
      "id": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ#ocap-invoke-key-1",
      "type": "Ed25519VerificationKey2018",
      "owner": "did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQ",
      "publicKeyBase58": "Gu5yfYsbYvmSeSsAbBBNafy9i6G3o5kiX5PxUGPg1iFJ"
    }
  }]
}

This is more of a question, and likely something we will address in the coming weeks.

In the BTCR hackathon, we observed we needed more fine-grained categories than "Proof of Ownership" vs "Proof of Control". This is described here and (I think) some other issues.

What's called "Proof of Authorization to Update" here appears to match the definition of "Proof of Control" from the DID spec -- i.e. ability to update the DDO. And "Proof of Control" here seems to match the definition of "Proof of Ownership" in the DID Spec.

To clarify, this is my understanding of how the words are used in the DID Spec vs Veres 1 Spec:

I'm opening this issue not as a bug, but instead to track these terms as we decide the right names and categories for key/proof types.

"Proof of Control" from the DID spec has caused a lot of confusion -- i.e. without context, it's not clear how it differs from proof of ownership. I prefer something precise, like "Proof of Authorization to Update" used here.

The DID URI points to web ledger spec :

[DID]
Decentralized Identifiers 1.0. Drummond Reed; Manu Sporny; Dave Longley; Christopher Allen; Ryan Grant; Markus Sabadello. Credentials Community Group. W3C Community Group Draft Specification. URL: https://w3c.github.io/web-ledger/

I cannot find in the specification how to revoke Veres One DID. Might be worth adding this.

Hello Manu & Dave,
My questions is should various DID methods be hosted on the W3C website - which makes them a standard?
My feeling is that a method is an implementation of the standards.
Best,
Dennis

Have anyone thought about more granular updating to the DID Document yet?

E.g. capabilityInvocation that allow a key to be able to update the serviceEndpoint section, but not the publicKey section. On one hand, I feel this is very beneficial for the principle of least authority. On the other hand, I feel the complexity isn't warranted at this point and it could be too much flexibility that could lead to people using DID Documents to easily miss-configure things that cause security issues.

@msporny @dlongley