Add did:andorra method to DID Method Registry

[davidgbvargroup]

This PR registers the did:andorra method in the W3C DID Method Registry.

• Specification: https://github.com/davidgbvargroup/did-andorra-method-spec/blob/main/spec.md
• Status: provisional
• Contact: David García Beatove (david.garcia@vargroupiberia.com)
• Verifiable Data Registry: Andorra National Registry (NRTAD)

----- DID METHOD REGISTRATION FORM: DELETE EVERYTHING ABOVE THIS LINE ------

DID Method Registration

As a DID method registrant, I have ensured that my DID method registration complies with the following statements:

• The DID Method specification defines the DID Method Syntax.
• The DID Method specification defines the Create, Read, Update, and Deactivate DID Method Operations.
  Note: did:andorra only supports Read (Resolve).
• The DID Method specification contains a Security Considerations section.
• The DID Method specification contains a Privacy Considerations section.
• The JSON file I am submitting has passed all automated validation tests below.
• The JSON file contains a contactEmail address [OPTIONAL].
• The JSON file contains a verifiableDataRegistry entry [OPTIONAL].

[swcurran]

The DID Method appears to create a one-to-one correspondence between Andorra National Registry identifiers and DIDs. Its not clear how or why the VDR is populated and in particular who controls the DIDs for the referenced identifiers. I can't see that the submit entity (vargroupiberia) has a presence online, so not sure what their role is.

I recommend more information about the DID Method be supplied before further review of the DID Method is carried out.

[davidgbvargroup]

Thank you for the feedback @swcurran
I have updated the specification spec.md (https://github.com/davidgbvargroup/did-andorra-method-spec/blob/main/spec.md) to clarify:

• The role of the Government of Andorra as the sole authority of the NRTAD registry.
• How the VDR is populated (only entities with a valid NRTAD identifier can request a DID).
• The role of Iberian Unit – Var Group as the appointed technology maintainer.
• The process of obtaining a DID, including issuance of a digital seal certificate.

Please let me know if further clarification is needed.

[ottomorac]

Hello @davidgbvargroup,

My feedback would be mainly on the "Security and Privacy Considerations section" which seems a bit short. It seems that each holder of an NRTAD ID is assigned a public key via certificate of some kind? I suggest you add some details on that process and perhaps some considerations on how the security of the certificate should be managed (or add details around what is the central authority managing the certificates of behalf of the DID holder if it is done on behalf of the user).

Ideally the "Security and Privacy Considerations" section. should have a few more items or at least a few paragraphs of the privacy and security implications of implementing your specification. Some examples here:

• https://identity.foundation/didwebvh/v1.0/#security-considerations
• https://docs.cheqd.io/product/architecture/adr-list/adr-001-cheqd-did-method#security-considerations
• https://github.com/iden3/did-iden3/blob/main/did-iden3-method.md#security-and-privacy-considerations

[davidgbvargroup]

Hello @ottomorac , thanks a lot for your feedback ,

I have expanded the Privacy & Security Considerations section to address your points:

• Added explicit explanation that the Govern d’Andorra is the central authority managing the NRTAD and the official PKI.
• Clarified that each NRTAD entity is issued a certificate signed by the Govern’s PKI, and that the public key from this certificate is what gets resolved through the DID.
• Documented how certificates are used (e.g., for signing verifiable credentials and verifiable presentation requests).
• Included details on certificate lifecycle management (issuance, rotation, revocation) handled exclusively by the Govern’s PKI.
• Expanded privacy notes to reinforce that DID resolution only exposes organizational identifiers and public cryptographic material no personal data or transactional information.

Let me know if this revision sufficiently addresses the concerns, or if you’d like me to provide even more technical depth about certificate handling and PKI governance.

[ottomorac]

Thanks @davidgbvargroup,

It it looking better now. One final thing I would suggest is that you clarify a bit about your trust assumptions of each Legal Entity that receives a certificate from NRTAD. How do the natural persons that can act on behalf on each Legal Entity handle their private keys? For example some keys are held in HSMs or smart cards and you would have a trust assumption that those are held securely.

Depending on how it works, there a certain trust assumptions and security considerations I think.

[swcurran]

Thanks for the updates. I'm happy that this registration request contains sufficient and appropriate information.

[davidgbvargroup]

Hello @ottomorac , thanks for the feedback,
I’ve updated Section 9 accordingly — it now includes a clarification on trust assumptions and key management. Specifically, it explains that private keys linked to NRTAD-issued certificates are securely managed by Qualified Trust Service Providers (QTSPs) under the national eIDAS framework, using hardware-based protection (e.g., HSMs).
Let me know if you think any additional clarification would be helpful!

[ottomorac]

Thanks @davidgbvargroup . The spec meets the minimum criteria. Approved.

[swcurran]

While not needed as part of the approval process -- I am curious in reading the spec. What is the use case for the keypair in the DID -- how / when / why does it get used.? From what I can tell, the public key is in a DIDDoc of a DID that is associated with a legal entity, but the private key is controlled by another entity. How does the private key get used and when it is used, what trust does it convey?

[davidgbvargroup]

Thank you for the question!
The keypair is used to sign Verifiable Credentials on behalf of legal entities registered in Andorra's national registry (NRTAD). When a company needs to issue an official credential (e.g., business certificate, tax compliance proof), they request the Govern's signing service to sign it using their DID's private key stored in government HSMs.
The signature provides dual attestation: (1) the credential represents a claim by a legitimate, government-registered entity, and (2) the Govern d'Andorra attests to the entity's legal standing and authority to issue such credentials.
I'd like to ask @ottomorac and @swcurran: What additional information would be needed for approval? Is there anything else I can provide to facilitate the process?
Thank you for your consideration!

[swcurran]

@msporny -- can you please take a look at this and see if it is ready for merging?

[davidgbvargroup]

Hi @msporny ,

Following up on @swcurran request for your review. The did:andorra method registration has been approved by both @swcurran and @ottomorac after addressing all feedback regarding:

-Role clarification of the Government of Andorra and the VDR population process
-Expanded Security and Privacy Considerations section
-Trust assumptions and key management details
-Use case explanation for the keypair and signing service

The specification is available at: https://github.com/davidgbvargroup/did-andorra-method-spec/blob/main/spec.md

Please let me know if you need any additional information or clarification to proceed with the merge.

Thank you!

[davidgbvargroup]

Hi @msporny, @swcurran, @ottomorac,

Thank you for approving and merging the PR!

I noticed that while the merge was successful, the lint workflow failed with a validation error on the status field:

[
  {
    instancePath: '/status',
    schemaPath: '#/properties/status/enum',
    keyword: 'enum',
    params: { allowedValues: [Array] },
    message: 'must be equal to one of the allowed values'
  }
]

The validator doesn't accept "provisional" as a valid value.

Should I submit a new PR changing the status to "registered", or is there a different status value I should use?

Thank you for your guidance!

[msporny]

Pushed a fix here: 1371241