-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DDOs as self-signed Verifiable Claims #8
Comments
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?
The text was updated successfully, but these errors were encountered: