There are a number of places in the spec where we list DIDs or public keys that are used to authorize certain actions like DDO modification, authentication to Verifiers/Relying Parties, etc. In each of these places, we seem to be gaining ambient authority problems. We will most likely want to take a capabilities-based approach to the security model across all Blockchains lest we fall into Access Control List and Confused Deputy hell.

We should explore how Macaroons could be used to accomplish delegation.

Update link: https://en.wikipedia.org/wiki/Zooko%2527s_triangle to https://en.wikipedia.org/wiki/Zooko%27s_triangle after PR #22 is merged

@gklyne wrote:

2. Hierarchical URI scheme? Is the scheme intended to operate in a hierarchical fashion? RFC 3986 defines a (hierarchical) reference resolution procedure that operates on any URI containing "/" characters (which are part of your "did-path" syntax. Conventionally, this works in conjunction with an "authority" component that is introduced by "//", but your scheme proposal does not use "authority" syntax. I'm not sure if there are any potential surprises in store if resolution is attempted with DID URIs.

There are three approaches that we could use for what keys can be used for in the DID specification:

1. Annotate keys so that you know whether they can be used for signing, encryption, authentication, etc.
2. Associate keys with capabilities instead of annotating those capabilities directly on the key.
3. A hybrid of 1 and 2, which is more complicated, but provides more flexibility.

Why not use RFC7517 in the DID spec when cryptographic keys are described as authorizationCapability?

So instead of

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authorizationCapability": [{
    // this entity may update any field in this DID Document using any
    // authentication mechanism understood by the ledger
    "permission": "UpdateDidDocument",
    "entity": "did:example:123456789abcdefghi"
  }],
  "exampleService": "https://example.com/messages/8377464",
  "authenticationCredential": [{
    // this key can be used to authenticate as DID ...9938
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaCryptographicKey",
    "owner": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }]
}

write something like

```json
{
  "@context": "https://w3id.org/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authorizationCapability": [{
    // this entity may update any field in this DID Document using any
    // authentication mechanism understood by the ledger
    "permission": "UpdateDidDocument",
    "entity": "did:example:123456789abcdefghi"
  }],
  "exampleService": "https://example.com/messages/8377464",
  "authenticationCredential": [{
    // this key can be used to authenticate as DID ...9938
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaCryptographicKey",
    "owner": "did:example:123456789abcdefghi",
    "key": {"kty":"RSA",
          "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
     4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
     tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
     QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
     SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
     w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
          "e":"AQAB",
          "alg":"RS256",
          "kid":"2011-04-29"
     }
  }]
}

Or extend jwk to include owner as id might equal kid and type equals kty...

You probably already considered this... 
Maybe you could use this issue to document the reasoning?

The spec needs to reserve the did:example DID Method for use in examples.

I would like to see DID Documents support the notion of keys/proofs being reliant on a combination of keys/proofs to be valid. Some attestations and auth requirements are what I would call 'mission critical', for example:

Say a government adopts decentralized identity systems, and integrates it into their court system. There may be many things that take just one signature from one key linked to the court entity to be authoritative, but some attestations may be so sensitive, with such a severe impact, that the court entity would want to put extra measures in place to up the ante on what it takes to be a valid attestation.

One such case: criminal conviction proofs.

In this case, a court entity may want to exclude any chance that a criminal conviction data object is ever created/signed with just a single key. They may want to specify that a set of three keys are reliant factors that must all sign something for it to be valid.

To do this, we could add a property on key descriptors that allowed the specification of another key in the owning entity's DID Document (or an external key ref, e.g. another DID's keys) that must be included for the key's use to be valid.

Pseudo code:

  {
    "id": "did:example:fooCountyCourt#keys-1",
    "type": "RsaCryptographicKey",
    "owner": "did:example:fooCountyCourt",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n",
    "factors": [{
         "id": "did:example:fooCountyCourt#keys-2",
         "requirement": "sig"
       },
       {
         "id": "did:example:courtClerkOne#keys-3",
         "requirement": "sig"
       },
       {
         "id": "did:example:courtClerkTwo#keys-1",
         "requirement": "sig"
       }
     ]
  }

I'm wondering if publicKey in the authorization section should be renamed to publicKeyURI to make it more clear about what it is.
Is there a use case where the actual key would be put there instead of the publicKey section?
All of our discussions so far have used it as a DID url for the key either in the same DID document or somewhere else. To keep things clean I would recommend that keys go in the publicKey section and authorization just uses DID urls to refer to them.
I'm not happy about publicKeyURI but I believe the name publicKey is not a good descriptor.

I recognize this is premature at this stage, but I wonder if anyone is talking about how we will start getting DID's into people's lives? Both as a thing that they possess (and understand) but also as a thing that is used. I'm very interested and passionate about self-sovereign identity, but conversations with my wife have shown that I'm not great at describing its importance. :)

I'd love to join up with anyone else thinking about the problem.

"Embedded" keys have an owner property that links back to their parent object in our examples, for example:

{
  "@context": "https;//w3id.org/did/v1",
  "id": "did:example:123456789abcdefghi",
  /* ... */
  "authenticationCredential": [{
    // this key can be used to authenticate as DID ...9938
    "id": "did:example:123456789abcdefghi#keys/1",
    "type": "RsaCryptographicKey",
    "owner": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }]
  /* ... */
}

This is confusing some readers; why should an object (or rather its embedded object) link back to itself?

In Linked Data Signatures, when we sign/etc things we need to link to a specific key, but we also need to know what the owner of that key is, and for security reasons that requires both the owner and the key link to each other. For example, of Manu makes a post saying "I like ravioli", the signature needs to link not just to Manu as the one signing it, which of Manu's keys specifically. So, this makes sense in LDS land generally.

The confusion is, in the example of a DID Document such as above, we don't have a ravioli object pointing to a key pointing to its owner, we have a DID linking to (or appearing to "embed") a key and linking back to itself.

The "linking back to itself" is the bit that's causing great amounts of confusion. :)

We could maybe drop the requirement to link back to its owner assuming we're using an "embedded" fragment identifier... but this would be incompatible with Linked Data Signatures, which has good reason to have this for the general case.

Navigate to https://w3c-ccg.github.io/did-spec/#specific-did-method-schemes

On the second paragraph, click on DID Method Registry link.

Results in Page not found for https://w3c-ccg.github.io/did-spec/did-methods.html

It would be great to have an easy link to the open issues database actually in the spec itself.

The page referenced in the DID v0.9 Draft as a DID Method Registry page is broken:
https://w3c-ccg.github.io/did-spec/did-methods.html

As discussed in the conversation about #22, the current language around DIDs slips into expansive language about "identities" where the more rigorous language really should be about "identifiers"

I'll start with the top level:

The emergence of distributed ledger technology (DLT), sometimes referred to as blockchain technology, provides the opportunity to implement fully decentralized identity management. In this ecosystem, all participants with identities (called identity owners) share a common root of trust in the form of a globally distributed ledger (or a decentralized P2P network that provides similar capabilities).

This sentence captures a broad disconnect I believe we can easily fix.

DIDs do not provide decentralized identity management. They provide decentralized identifier management.

There's a huge difference.

We're generally on the same page about the opportunity for decentralized identity, but DIDs are just the first step and I think we would do better to be strict in our claims.

DIDs do not address attribute management (classic ISO definition of identity), nor do they address attribute derivation, analysis, use, and protection (from the functional definition of identity).

I started adding a bunch of +1 to @dlongley's comments for replacing "identity owner" with "entity" and realized a simpler, but more sweeping change to focus on DIDs as providing a means to prove control of "identifiers" rather than "identities" would greatly improve the entire spec.

Note that even with the stricter language of identifiers and the smaller scope, DIDs still solve a unique problem in a way that is game changing. I'd like to see we capture that in the most elegant and modest manner possible without conflating DIDs with much larger issues they don't actually address.

The current consensus in the group seems to be that service descriptions looks something like this:

{
  "id": "did:v1:1234567",
  ... // DID Document goes here ...
  "service": [{
    "type": "urn:foobar:MessagingService",
    "name": "messaging",
    "serviceEndpoint": "https://example.com/messages/398tuo"
  }]
}

... which could result in the following URL that uses the service above:

did:v1:1234567;messaging/somepath#somefrag3

I suggest that we remove name and move to a less error prone format:

{
  "id": "did:v1:1234567",
  ... // DID Document goes here ...
  "service": [{
    "id": "did:v1:1234567;messaging",
    "type": "urn:foobar:MessagingService",
    "serviceEndpoint": "https://example.com/messages/398tuo"
  }]
}

Note that we get rid of the name field and use id instead. This approach has the following benefits:

1. It fits with the JSON-LD model more cleanly,
2. doesn't require implementations to destructure a URL and look for specific properties (opaque identifiers),
3. avoids the creation of a scenario where the id and the constructed service URL can differ, and
4. enables us to use the semicolon syntax to address things that are not just service endpoints in the document.

Does the guardian field duplicate functionality provided by the control field?

The current DID spec draft lists several examples of services, e.g. socialWebInboxService and credentialRepositoryService.

From what I can see:

1. In the DID LD-context, there are no terms related to services
2. The DID spec does not specify a data model for service endpoints, just examples like Extensible Data Interchange.

Is this correct? If so, then my current understanding of service endpoints is:

3. method specs define terms in their LD context
4. method specs define (or point to) the data model for service endpoints

Is this also correct?

A few points on 4.7 "Signature (Optional)" and 7.2.1 "Proving Ownership of a DID and DID Document"

a) The spec in 4.7 says "A signature on a DID Document is cryptographic proof of the integrity of the DID Document". However, in the BTCR method, it isn't truly a signature, it is a proof. It only confirms the first private and public key, the timestamp, and the DID document URL.

This is what currently is being proposed.

"signature": {
    "type": "SatoshiBlockchainSignature2017",
     "chain": "testnet3",
    "blockhash": "00000000b3487880b2814da8c0a6b545453d88945dc29a7b700f653cd7e9cdc7",
    "blockindex": 1,
    "blocktime": 1499502050,
    "time": 1499501000,
    "timereceived": 1499501000,
    "burn-fee": -0.05
  }

Using the proof of that first key now can be used for another signature that can be used for integrity of additions to the DID document.

  "signature": {
    "type": "EcdsaKoblitzSignature2016",
    "created": "2017-07-16T00:48:44Z",
    "creator": "ecdsa-koblitz-pubkey:02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71",
    "signatureValue": "HyV/c/DFdAigxSAuqE9O6yRqUk5wpobUaj63ig3hZMZxKJ/l2lNduWFKsN6aR5twAFurD3pJx2ZgVpu/fRb/lLo="
  }
}

b) I think the early examples should show some signature.

The did-spec uses RsaSignature2017 seven times but never defines it or references a specification that specifies it.

I suggest to use RFC7518 signatures whenever the did-spec specifies a cryptographic signature algorithm.
What is the status of https://w3c-dvcg.github.io/lds-rsa2017/ ?
Is there a @w3c working group moving it to recommended standard?

See #38 for the general issue.

We need to create a JSON-LD context for the DID spec.

I propose that "authenticationCredential" be renamed to "authenticatorMechanism" or just "authentication". This is more general and gets away from the term "Credential" which has been overloaded over the years. My preference is "authenticationMechanism".

I note that the EXAMPLE 5 uses "authentication"

From @ChristopherA on July 13, 2017 18:19

One of the insights from this hackathon is that the DDO can be a composite object.

We have the deterministic part that is, in effect, signed by the blockchain. In BTCR this part verifies an persistent unique confirmed identifier (the txref that is an encoding of chain, block and index), another unique by unconfirmed identifier (the txid), one owner key (which signed the transaction), one control key identifier (the hash of a future key to be revealed), and a pointer out. But nothing more. However, in Sovrin, in effect everything is signed by the blockchain.

Since I don't think you can override anything in BTCR that is deterministic, that means having any there is redundant. So we can some some current problems with IPFS objects as we can create there DDOs that don't include the txref. All that is required is that it is singed by the owner key.

In a sense, the object pointed to on the op_return is a self-signed verifiable claim from the owner key in the deterministic part that appends more information to the deterministic part.

Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#37

Based on the "Truths about Biometrics" paper drafted at RWOT6, it was recommended that biometric data (partial or encrypted) should not be in a DID Document. Rather, only service endpoints (URLs and otherwise) to any biometric services (partial or encrypted) should be in a DID Document. Please remove all biometric template and use service endpoint examples (e.g., BOPS, etc.)

The spec does not yet define what authenticationCredential is

Please explain and spec RsaSignature2018. What does it mean that the proofType has this value?

The same for RsaVerificationKey2018, please.

As long as these values appear only in examples and non-normative text they can mean anything.

AGREED:

• fragment being absolute is a SHOULD (or, relative fragments are a SHOULD NOT)
• authenticationCredential is included in a document even if it's generated dynamically eg in bctr
• credentials should be scoped properties eg authenticationCredential instead of credentials
• owner is currently used by many LDS types, but it is possible to define a type that would fit in a credentials slot that does not need owner if it can justify inference

NOTES:

• terminology conversations are endless, but what we're calling permission object capabilities people call methods

Why not reference RFC7518 to specify cryptographic algorithms?

I think the did-spec should reference rfc7518 whenever cryptographic algorithm names need to be specified.

Proposal to add "revocationAuthority" property into "revocation" object. Please, see below.

...
"revocation": {
    "id": "http://example.gov/revocations/738",
    "type": "SimpleRevocationList2017"
     "revocationAuthority": "did:example:ebfeb1f712ebc6f1c276e12ec21"
  },
...

The idea is to have explicitly stated who has the right to revoke credential. Usually it will be issuer, but it can also be other DIDs.

I find the delegation model a bit complicated and have been reflecting on a more generic pattern.

I believe there is an implicit assumption that a DID "owner" is also the "controller" unless by exception by means of delegation. I don't think this is necessarily the case.

I think you can address the delegation aspect more generally by removing it and introducing the notion of "controller" along with "owner". You can prove "ownership" and/or "controllership"

In the majority of cases, owner and controller are the same subject, but in the case of delegation (guardian) the controller would be a different subject.

Further, by separating owner/controller it allows you to implement hybrid centralized/decentralized identifier/authentication schemes. For example, my email address "[email protected]" is a centralized identifier, but I may wish to register and prove controllership in a decentralized context that is completely unrelated to Google.

Finally, you can have two independent lifecycles (or transitions) - one for ownership, and another for controllership. A good real-life example is the differentiation between the owner of a vehicle and the driver of the vehicle. Speeding tickets are attributed to the driver of the vehicle; parking tickets are attributed to the owner of the vehicle.

Anyway, these are suggestions to help simplify the spec.I may have missed some nuances in the model but happy to discuss further.

As explained here – https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/topics-and-advance-readings/DID-Method-erc725.md by @peacekeeper –

"In Ethereum, looking up a raw public key from a native 20-byte address is a complex and resource-intensive process. The DID community may want to consider allowing hashed public keys in the DID documents instead of (or in addition to) the raw public keys. It seems this would make certain DID methods such as erc725 much simpler to implement, while at the same time not really limiting the spirit and potential use cases of DIDs."

Will it be possible to add to DID spec "publicAddress" property (with the same rules as for publicKey property)?

When keys are being revoked are there any recommendations on whether they should remain in DDoc or be removed comletely?
When checking validity of signature in a credential there is a need to check if the key of a signer was revoked at the time of signing. To do this check there should be a way to check all DID's keys and retrieve their revocation timestamps.
I would think that to make this check easier it would be better to keep revoked keys in DDoc, but in the spec I see only examples of complete keys removal.
Will it be allowed in DID Method spec to have revoked keys stay in DDoc? Maybe we can add "keyRevoked" and "keyRevocationTS" properties?

We need to either describe @manu's term end of day result of an "entity profile" or "persona" and/or come up with a new name for it.

We need a vetted description for the Ed25519 key format. The one in the spec right now is just a first guess at what one might look like. We need an implementer to put a more rigorous example into the spec.

From @dckc:

The future of the 'did:' prefix will most likely track what happened with the 'urn:' registry, in that there will be DID methods that people use, and others that people won't. This leads to the prefix becoming fairly useless as a differentiating piece of information over time. The suggestion is to get rid of it and just depend on the IETF scheme registry where each DID Method registers itself as a new scheme.

So, instead of "did:foo:...", we just register the 'foo' scheme at IETF for the foo ledger.

Also, from @gklyne:

You say "Conceptually, the relationship of this specification and a DID method specification is similar to the relationship of the IETF generic URI specification ([[RFC3986]]) and a specific URI scheme" - to me, it feels more like the relationship between the URN specification and a specific URN namespace ID. The way you describe it, it sounds like a reinvention of URIs within URIs, and begs the question: why not just use a separate URI scheme for each distributed identifier method, with the DID specification aiming to be something that can be included by reference into any new DID scheme?

points to opencreds

The owner field really holds a list of public keys. We should call it publicKey. We may have a problem with publicKey as well as there seems to be "ambient authority" associated w/ that term. We may want to move to a capabilities model for all of this sort of stuff.

Services are listed off of service at present. We should replace it with serviceUrls.

Should we use singular or plural form for property names. That is, is it service or services, publicKey or publicKeys?

I would like to propose that DDO is defined as a "DID Descriptor Object" that is the minimum necessary to bootstrap the into a Linked Data graph model that can fully discover and construct the EDO or "Entity Descriptor Object".

Thus the DID/DDO spec should be about:

a) What at minimum should a DID methods define.

b) What is required to create a DDO that is minimal LD (Linked Data) object that can be bootstrap into a larger EDO.

c) What is require for other parts of the LD graph to prove that they are associated or issued by the DID (what we are currently calling "owner" proofs).

d) What is required for an an updated DDO LD object to prove that it has updated or revoked the old DDO LD object (what we are are currently calling "control" proofs),

e) A pointer(s?) to bootstrap discovery of additional LD objects that are associated with the DID owner proof to establish the constructed EDO (without this pointer the alternative is that the inspector has to discover what they can from info that they know, which is acceptable thus this pointer is optional).

I think it is up to the method spec to define what proofs are required for the issue of claim from this DID. In the BTCR method, the owner proof key is only allowed be a issuer proof key and prove claims if there there are no issue claim proof keys in the EDO graph that are owned by the the DDO.

From @kimdhamilton on July 22, 2017 16:46

From @ChristopherA on July 14, 2017 7:31

An insight from the work this week is we should not be talking about owner key, or control key, etc.

Instead, we should be talking about proofs.

For instance, this fragment from a DDO

  {
          "control": 
          [{
              "control-bond": 1.25
              "rotate-proof": [{
                  "proof-type": "pubkeyhash",
                  "bond-value": 1.25
                  "hash-base58check": "mvZ3MyLgsvYr87GGSbsPBWEDduLRptfzEU"
                  }]
            },{
            "revocation-proof": [{
                "bond-value": 1.25
                "proof-type": "pubkeyhash",
                "hash-base58check": "mvZ3MyLgsvYr87GGSbsPBWEDduLRptfzEU"
          }]
        }

It basically says that for control (which permits rotating the owner key and the DDO address) that there are two subtypes, a rotate proof and a revocation proof. In another ddo system the proof-type could be "signature", or even "revocation list".

Similar with owner (which permits updating of the keys allowed to issue claims, and the other content of the DDO, but not the control key or the DDO address), it can be proofs as well which may not just be signatures.

cc: @talltree @msporny @dlongley

Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#39

Copied from original issue: w3c/vc-data-model#62

In the authentication section it says

2. The value of the authentication property should be an array of proof mechanisms.
3. Each proof mechanism must include id, type, and owner properties.

This is not correct, I don't see "id" or "owner 'in any of the examples and I thought the only required field is "type". Because each proof mechanism MAY be a key description of a valid public key or verification key. A new key description MAY also be defined by a DID method specification.

This appears as a free-flowing paragraph, the original seems to be formatted to expect fixed-layout tags

"
did-reference = did [ "/" did-path ] [ "#" did-fragment ] did = "did:" method ":" specific-idstring method = 1*methodcharmethodchar = %x61-7A / DIGIT specific-idstring = idstring ( ":" idstring ) idstring = 1idcharidchar = ALPHA / DIGIT / "." / "-"

"

I'm putting together a triaged bug list that hopefully walks us through the issues in a way that generates solutions to the low level problems before tackling the higher-level ones. Here's the suggested order:

1. Proofs or signatures?
   • #15: proofs, not keys
2. Capabilities security model?
   • #11: capabilities-based delegation model
   • #10: should keys describe what they are used for?
   • #4: ambient authority w/ 'owner'
   • w3c-ccg/did-method-v1#1 (comment): separation of concerns
3. How are DID-based authentication credentials specified?
   • w3c-ccg/did-method-v1#1 (comment): authenticationCredential field
4. How is DID Document update authorization specified?
   • #6: boolean logic in control field
   • w3c-ccg/did-method-v1#1 (comment): authorization field
   1. Determine how guardianship is supported
      • #8: guardian field duplicates control field?
      • w3c-ccg/did-method-v1#1 (comment): authorization field
5. Determine how Verifiable Claim issuance is done from a DID Document.
   • w3c-ccg/did-method-v1#1 (comment): how to issue?
6. Determine how services are listed
   • #7: remove service field

Why is "type": "RsaCryptographicKey" not split into "algorithm": "rsa" and "type": "cryptographicKey"?

If the answer is "Because there will only ever be cryptographic keys as types", then why do we even have the string 'CryptographicKey' attached to it?

I was thinking on how to make audit of DID Document updates as easy and as transparent as possible.
How resolver of DID makes sure that it has that latest version of DID Document? If resolver needs to get the whole history of DID Documents for DID how it makes sure that it has a whole history without any omissions?
I realise that this is DLT and DID method specific, but still are there any recommendations or explanation of the best way it should be done or about MUST requirements for this. Are any explanations of this for implemented DID Method specifications availalble?

Also, to make audit of DDoc history as transparent and as simple as possible I propose to add "updateNumber" property to DID Documents. On every DDoc update the value of updateNumber MUST grow by 1. Two or more DDocs with the same updateNumber, but with different content are NOT ALLOWED. This property would allow to have a clear audit trail of changes. It will allow to know from one glance how many changes happened with that DDoc.

From @ChristopherA on July 8, 2017 4:14

I tried to puzzle through a valid DDO as a verifiable claim at https://raw.githubusercontent.com/ChristopherA/self/master/ddo.jsonld a number of issues came up.

{
  "@context": [
    "https://schema.org/",
    "https://w3id.org/security/v1"
  ],
  "id": "DID:BTCR:TBD#SOMEVALUE",
  "type": [
    "Credential",
    "WebOfTrustCredential"
  ],
  "issuer": "DID:BTCR:TBD#SOMEOTHERVALUE",
  "claim": {
    "id": "DID:BTCR:TBD#SOMETHIRDVALUE",
    "alternatename": "ChristopherA",
    "url": "https://raw.githubusercontent.com/christophera/self/master/ddo.jsonld",
    "publicKey": "02c490e19e936efab022bd9fc12833db082706473fd96cec14c4a8dac058a0dbee"
  },
  "signature": {
    "type": "EcdsaKoblitzSignature2016",
    "created": "2017-07-08T00:21:53Z",
    "creator": "ecdsa-koblitz-pubkey:1P8BWgokGDiqPYc3kgDDgn5Vm9XD1YUjEe",
    "signatureValue": "H/2e5KiopVH3glkoDf/yP/dwScEP0HPZioxNffvalkyUFYDX7OJ/4uKs6gPqjCISpR3DUe1PKTOVE6MSSTS8AeE="
  }
}

First as per #21 we don't have the right format for koblitz public keys (ecdsa-koblitz-pubkey isn't a public key, it is a hash). There are questions regarding issuer and owner.

But there are a number of questions about the ID numbers.

First, walking through the scenario: We will have a master public key that is same as the one on the DID transaction. I presume this is what the DDO verifiable claim would be signed with. I presume this key can be referred to as "DID:BTCR:TX1RK63UVXF9PQCSY" (btw, @jonasschnelli's actual DID).

It there is no DDO (which would be true for DID:BTCR:TX1RK63UVXF9PQCSY) that key is the only key — there are no others.

However, if the DDO exists it could, and probably should, have other public keys in it. As long as the key signing the DDO has not been revoked, they can be used to sign other verifiable claims (possibly with some future designe limitations). These keys could be non-koblitz keys (for instance, my PGP key or my 25519 miniLock key (BTW, which is 7rXYBKi1Xf9g9nupb9f8u6MHbobEJCMK3r3sChjN5RmGN )

How should we point to these other keys? I presume that is where the #SOMEVALUE is used. In the DID spec these are called DID Fragments:

DID fragment. The portion of a DID reference that follows the first hash sign
character ("#").

A DID fragment MUST be used only as a method- independent pointer into the DDO
to identify a unique key description or other DDO component. To resolve this pointer,
the complete DID reference including the DID fragment MUST be used as the value of
the id key for the target JSON object.

So in my example above, is the public key in my claim # 1? How do we mark them? For my prototype, I'd like be able to refer to 3 keys, a master koblitz, a second koblitz only valid for signing keys during the duration of this ddo, and my pgp key.

Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#23

From @rxgrant at RWoT6:

The spec currently doesn't explain why we're depending on graph-based data models and JSON-LD for extensibility. It also doesn't explain when you can and/or shouldn't process the document as pure JSON. We should add a section explaining this architectural decision. Mention the expectation that developers will parse DID Documents with common libraries (e.g. what happens when "owner" doesn't exist).

We should register the DID URI scheme here:

https://www.iana.org/assignments/uri-schemes/uri-schemes.xml

At present, the control field (which should probably be renamed to didControl)... contains AND and OR controls. We should type these to something like "Multisignature2017" note the version on the signature.

From @ChristopherA on July 13, 2017 18:24

We have a problem in our DID specification where we are assuming that owner keys are what is also used for signing claims. This is causing us a number of problems in the BTCR method.

What we are discovering is that what the spec says owner key is used for is overloaded.

Instead, I suggest that the owner key(s) are ONLY used for signing DDO objects.

What we need is another list, with a name TBD but is basically the "claim issuer keys", which are in a DDO, signed by the owner keys, which are keys allowed to be used to sign names. This list may, or may not, include the owner key, but if the list doesn't exist, then the owner key is presumed to be one of them.

cc: @talltree @msporny @dlongley

Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#38