Closed ChristopherA closed 7 years ago
It's exactly as @ChristopherA says, but keep in mind that our DDO implementation is going on 2+ years old at this point. Here's an example of a DDO for our current system:
https://demo.authorization.io/dids/did:2ba2d687-2f92-4c4a-aa45-e3e8a6ae38a1
We'll be revamping it over the next couple of months to align w/ the new DID spec. We expect to suggest changes to DDO objects.
To be clear, a DDO can be thought of as an Entity Profile (from Verifiable Claims). That is, it's a signed document that can contain a set of Credentials (which contain Verifiable Claims).
@ChristopherA which repo should we move this to?
I our prototype, ddo fragment /0 is signed by the blockchain itself (in our case, bitcoin) which points to the next fragment (in our case, through the op_return), and the /1 is a self-signed claim that adds claims about the entity that issued the did. Fragment /1+ could contain more claims, either issued by the did issuer, or accepted from others about the did issuer that the issue accepts.
This issue was moved to w3c/vc-data-model#61
The current DID implementors spec for DIDs just has the DDO being a signed JSON-LD blob.
I've always been inclined that instead it should be a self-signed verifiable claim, pointing to itself. This may be a minor point but that is the way I've always thought of the trusted root ever since the days of Ronald Rivest's SDSI.
I believe this is what @msporny and @dlongley are doing with their DDO method. Can you guys share what your DDO looks like?