docs: add migration guide for Indy to did:webvh AnonCreds issuance#4059
Conversation
Adds a strategic guide for issuers transitioning from Indy-based AnonCreds credentials to did:webvh-rooted ones. Covers prerequisites, dual-issuance transition strategy, step-by-step setup, and impact on controllers and verifiers. Closes openwallet-foundation#3885 Signed-off-by: Patrick St-Louis <patrick.st-louis@opsecid.ca> Co-authored-by: Cursor <cursoragent@cursor.com>
esune
left a comment
esune
left a comment
There was a problem hiding this comment.
Looks good to me, it should be enough for issuers and verifier to at least get started and work towards migrating.
| 1. Set up the did:webvh infrastructure (server, witness, plugin) alongside | ||
| your existing Indy configuration. | ||
| 2. Create a did:webvh DID for your issuer. | ||
| 3. Re-register your schemas and credential definitions under the new DID. |
There was a problem hiding this comment.
I don't think the "Re-" is needed -- these are new objects. Picky, picky...
swcurran
left a comment
swcurran
left a comment
There was a problem hiding this comment.
Overall a really good document. Let's debate my points. As well, consider framing this as a generalized way to transition issuing from one credential format/type to another. I'd like the document title to change, but the general transition model can be repeated in other scenarios.
|
@swcurran I think a lot of this comes down to, how much should the issuer be limited by it's ecosystem? If an issuer needs to wait for all holders and verifiers to support their updated components, this creates a limitation on the least up to date entity. Its hard to describe this in an upgrade guide with a decentralized ecosystem in mind. An issuer might not have a way to contact all verifiers. I think a lot of this wording can be massaged in the "transition" phase. Issuers might not know which wallet software stores their credentials, same for verifiers. Issuers can publish a notice of their upcoming changes, but may not have direct line of communication with wallet / service providers. |
|
They might have "critical" lines of business where they just must keep issuing indy until all parties have updated their software, which may or may not be aligned with the issuer's technological choices. |
|
Let's discuss. We can call these out, as you say, but what is the "recommended" way? I think the recommended way to get the holders/verifiers software updated/ready (as best you can in a decentralized world), and then do the transition. If the criteria for keeping to issue the Indy-rooted credentials, how do you know what holder software has been updated? AFAIK the "discover features" protocol -- as useful as it is -- is not broadly implemented, and doesn't cover (for example) Indy to did:webvh transitions. |
…assumption and ongoing Indy credential management Signed-off-by: Patrick St-Louis <patrick.st-louis@opsecid.ca>
…py into docs/indy-to-webvh-migration
|
Addressed review feedback: reframed the guide around the full issuance process and a planned cutover (not dual-issuance), added the assumption that issuers/holders/verifiers already support did:webvh, and called out sharing new identifiers with verifiers before cutover and the need to keep managing already-issued Indy credentials (e.g. revocation). Also applied the copy edits (Phase 3 title, "register" not "re-register") and noted the pattern can apply to other VDR transitions. |
|
|
||
| ## Key Differences at a Glance | ||
|
|
||
| | Aspect | Indy | did:webvh | |
There was a problem hiding this comment.
A relative minor issue, but let me know what you think -- maybe a note early in the document? What you have in this table the "did:webvh Server AnonCreds Method" where the implementation is opinionated -- there is two extra elements in the DID (ns and id), plus a defined path to the resource. did:webvh itself can support any scheme -- "plain" did:webvh DIDs (no extra elements), any DID URL path. So we at least need to call that out vs. implying that this is what did:webvh requires.
It's too late for this, but I've wondered silently if the path should contain metadata such /resources/anoncreds-schema/{digest}. Did you consider that? Or the same mechanism that Indy used -- with the object type enumerated in the identifier.
There was a problem hiding this comment.
It's too late for this, but I've wondered silently if the path should contain metadata such /resources/anoncreds-schema/{digest}. Did you consider that? Or the same mechanism that Indy used -- with the object type enumerated in the identifier.
We can explore adding a resource type slug to the url, and require all attested resource to include this slug in their id. Since this is not currently the case, lets leave it out of the doc for now.
swcurran
left a comment
swcurran
left a comment
There was a problem hiding this comment.
Some comments that I think would make it a bit better (although it is great already). The only change is a clarification somewhere (presumably in the intro) that references the did:webvh AnonCreds Method is meant when it talks about switching to "did:webvh".
- mkdocs: rename nav entry to 'Migrating AnonCreds Issuance from Indy to did:webvh' - Add Phase 4 (Remove Indy) with verifier/issuer notification and config cleanup - Phase 2: expand verifier readiness (libraries + presentation request OR) - Phase 2: add before/after example for presentation request restrictions - Table: expand Indy identifier format with schema/cred def/DID elements - Add note that did:webvh column describes Server AnonCreds Method convention Signed-off-by: Patrick St-Louis <patrick.st-louis@opsecid.ca> Made-with: Cursor
|
@swcurran I think I've addressed all your suggestions, aside from including a resource type slug in the uri! |
|
3 participants
Adds a strategic guide for issuers transitioning from Indy-based AnonCreds credentials to did:webvh-rooted ones. Covers prerequisites, dual-issuance transition strategy, step-by-step setup, and impact on controllers and verifiers.
Closes #3885