DID doc should be serialized before hashing to get the DID

[lovesh]

Signed-off-by: lovesh lovesh.bond@gmail.com

[dhh1128]

@lovesh I don't think we need to canonicalize. That's one of the key evolutions in my thinking since I first started working on this topic. What has to be signed is the bytes of a DID doc in any valid format. We sign the raw bytes, uncanonicalized. Then we sign deltas, which are also raw JSON with no canonicalization requirement. The magic here is caused by several things:

• All items in a DID Doc have unique IDs, so we can tell them apart without caring about order.

• All items in the DID Doc are immutable, so we never have to deal with modifications--only with adding and deleting.

• Deleting an item means adding its ID to the deleted list.

• Because of the first three choices, the order in which deltas are applied often doesn't matter. (Yes, I know there are cases where it still does matter, and I need to write a 1-page section of the spec about this, but just trust me for the time being that I've thought about this and that it's better to think about order as being irrelevant for the purposes of the present discussion.)

• The genesis DID doc is just deltas[0].

• Deltas are signed as a raw byte stream. The deltas {"deleted": ["key-1"]} and:

{
    "deleted": [
        "key-1"
    ]
}

...mean the same thing, but we don't care. They are different byte sequences and thus produce different signatures. Whichever form was used by the party that makes a change is the form we'll apply.

• The hash that represents current state of a DID doc is NOT a hash of its bytes; rather, it's a hash of all applied deltas.

[dhh1128]

@lovesh Do you think we can close this issue, or do you want to have more discussion?