search

decentralized-identity / universal-registrar

Universal Registrar implementation and drivers.
https://uniregistrar.io/
Apache License 2.0
76 stars 25 forks source link

Hoqto update a did:sov #68

Open andreas-c-hofmann opened 1 year ago

andreas-c-hofmann commented 1 year ago

Hi there,

I want to update a did:sov and I´m not sure, whether it´s not working or I´m going the wrong way. Are there any Howto´s for this scenario.

Im getting an Error 500, which points to an internal error.

My course of action:

  1. I copied the complete Scret, I got by creating the did into the SECRET-field.
  2. I copied the complete DID-Document as shown by the resolver in the DID-Document-field and edited the changes.

I really appreciate this new developments of DID.

Thanks for your help! Andreas

peacekeeper commented 1 year ago

Hello @andreas-c-hofmann , in general your approach is correct with regard to the API and protocol, i.e. yes the idea is that you could pass the secret and the new DID document to update the DID. But unfortunately in the open-source did:sov registrar driver this isn't implemented yet (see https://github.com/decentralized-identity/uni-registrar-driver-did-sov/).

There's also a (non-open-source) service at https://godiddy.com/ where create/update/deactivate are possible for did:sov, did:indy, and others. This builds on top of the open-source DIF components.

Note that there is also an alternative architecture for a DID registrar service, where the secrets are not passed back and forth, but instead always stay on this client side, this is called "client-managed secret mode": https://identity.foundation/did-registration/#client-managed-secret-mode

Hope this helps..

andreas-c-hofmann commented 1 year ago

Hi,thanks for your reply and explanations.Are there any DID-methods, that could be administered in complete by the open source version?Regarding godiddy, I only had a first glimpse at it. I am not sure, whether I could administer DIDs created by another registrar.Client-managed DIDs sounds quite good and is a consequent understanding of decentralized administration - the core of DIDs. I'll look it up as well. Unfortunately I do not have any developer's competence, If that were a requirement.Again, many thanksAndreas --Dr. Andreas C. Hofmannwww.andreashofmann.euMobil: +49 176 80066446 -------- Ursprüngliche Nachricht --------Von: Markus Sabadello @.> Datum: 23.01.23 10:05 (GMT+01:00) An: decentralized-identity/universal-registrar @.> Cc: "Andreas C. Hofmann" @.>, Mention @.> Betreff: Re: [decentralized-identity/universal-registrar] Hoqto update a did:sov (Issue #68) Hello @andreas-c-hofmann , in general your approach is correct with regard to the API and protocol, i.e. yes the idea is that you could pass the secret and the new DID document to update the DID. But unfortunately in the open-source did:sov registrar driver this isn't implemented yet (see https://github.com/decentralized-identity/uni-registrar-driver-did-sov/). There's also a (non-open-source) service at https://godiddy.com/ where create/update/deactivate are possible for did:sov, did:indy, and others. This builds on top of the open-source DIF components. Note that there is also an alternative architecture for a DID registrar service, where the secrets are not passed back and forth, but instead always stay on this client side, this is called "client-managed secret mode": https://identity.foundation/did-registration/#client-managed-secret-mode Hope this helps..

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>