add did:finger method

[youngseokaaa]

Instructions for Pull Requests

Please read these instructions thoroughly in order to ensure that your pull request is processed in a timely manner. This document contains detailed instructions for registering a DID Method. If your pull request concerns some other change to the repository, you may delete all of the text in this text box and write up a more relevant description.

There is a DID Method Registration form below that MUST be included in a DID Method Registration Request. The form includes check boxes that you are expected to fill out when you submit your request.

Once you submit your request, your pull request will be reviewed by the registry editors. Changes regarding the required criteria may be requested. If there are no objections or changes requested, your DID method will be registered after a minimum of 7 days.

DID Method Registration Process

In order to register a new DID method, you must add a JSON file to the ./methods directory.

Here is an example registration entry:

{
  // These fields are required
  "name": "example",
  "status": "registered",
  "specification": "https://w3c-ccg.github.io/did-spec/",
  // These fields are optional
  "contactName": "W3C Credentials Community Group",
  "contactEmail": "",
  "contactWebsite": "",
  "verifiableDataRegistry": "DID Specification"
}

Your Pull Request will be automatically validated, please ensure that all of the automated tests pass (no errors reported) or your submission will not be reviewed. Common reasons for failed validation includes invalidly formatted JSON files and missing mandatory fields.

----- 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.
• 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].

[ottomorac]

Hello @youngseokaaa ,

Thanks for your submission. Upon reviewing there are a few items you need to address:

• Whilst you indicate which DID methods are supported, you do not indicate how they operate. For each DID method operation that you support (Create, Read, Update, and Deactivate DID Method Operations). You should provide detail of how they function. See some examples here:

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

• While you do have a "Privacy & Security Considerations" section you need to discuss security considerations around those in more detail. The section should discuss some aspects public/private key handling and any other privacy and security implications of implementing your specification. Some examples here:

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

• There should be more details around the implementation libraries of the DID method itself (which you indicated was developed in Go), it should be clear how anyone could use this to write a DID resolver or any piece of software using the DID Method. You mention APIs are used, ideally there should be links to documentation of how those APIs function.

• Finally, the contact website you have indicated seems to be invalid: https://github.com/finger/f-did_go , please correct to the right one

Let us know when you have addressed these points, and we can review again. Thank you.

[youngseokaaa]

Hello @youngseokaaa ,

Thanks for your submission. Upon reviewing there are a few items you need to address:

• Whilst you indicate which DID methods are supported, you do not indicate how they operate. For each DID method operation that you support (Create, Read, Update, and Deactivate DID Method Operations). You should provide detail of how they function. See some examples here:

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

• While you do have a "Privacy & Security Considerations" section you need to discuss security considerations around those in more detail. The section should discuss some aspects public/private key handling and any other privacy and security implications of implementing your specification. Some examples here:

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

• There should be more details around the implementation libraries of the DID method itself (which you indicated was developed in Go), it should be clear how anyone could use this to write a DID resolver or any piece of software using the DID Method. You mention APIs are used, ideally there should be links to documentation of how those APIs function.

• Finally, the contact website you have indicated seems to be invalid: https://github.com/finger/f-did_go , please correct to the right one

Let us know when you have addressed these points, and we can review again. Thank you.

Hello @ottomorac

Thank you for the detailed feedback on my submission.

I have updated the DID Method: finger specification to address all of the points you raised:

1. Method Operations: Added detailed step-by-step descriptions for each DID method operation (Create, Read/Resolve, Update, and Deactivate), including the specific processes and authentication requirements for each operation.

2. Security & Privacy Considerations: Significantly expanded the "Privacy & Security Considerations" section with comprehensive details on:

   • Public/private key handling and management
   • Signature canonicalization and verification processes
   • Authentication and access control mechanisms
   • VDR trust model and residual risks

3. Implementation Details: Added clear implementation guidance including:

   • Detailed steps for implementing a DID Resolver
   • API endpoints documentation with authentication requirements
   • Signature serialization process (using Go's json.Marshal)
   • Code examples for DID generation

4. Contact Information: Corrected the contact website field (removed the invalid GitHub URL).

The specification now clearly documents the canonicalization approach, authentication model for Update/Deactivate operations, and the VDR trust assumptions, addressing all of your review comments.

Could you please review the updated specification when you have a chance? I'm happy to address any additional feedback you may have.

Thank you again for your thorough review and guidance.

Best regards,
youngseokaaa

[ottomorac]

Thanks @youngseokaaa . The did method registration proposal meets the requirements. Approved.

[swcurran]

The specification is complete and thorough, and so sufficient for registration. I note that I could not find any information about "Finger, Technology Research Institute", nor could I access a web site of the email address. Likewise, the GitHub repo said nothing about the entity behind the specification. I'll defer to other that approve registrations about the need for such information before approval.

It looks like the DID is just stored in a central database -- which is fine. I'm curious about the use case and purpose for defining the DID Method.

[youngseokaaa]

Hello @swcurran

Thank you very much for your careful review and thoughtful feedback.

Before summarizing the updates, I would like to briefly clarify the context of this work.
I am based in South Korea and work at Finger Co., Ltd., and this DID Method specification is being developed as part of an ongoing project by the Technology Research Institute team within Finger. The work is conducted as part of our company’s internal R&D activities around decentralized identity, key management, and Verifiable Credentials, with the intention of applying W3C standards in real-world production environments.

Based on your comments, I have revised the did specification and would like to summarize the updates below.

1. Organization and Contact Information

Organization: Finger Co., Ltd., Technology Research Institute (Finger, Technology Research Institute)

Website: https://www.finger.co.kr/homepage/html/main/main-01-01.html?cate=main&sub=01&page=01

Contact: youngseoka@finger.co.kr

The specification now clearly states that the did method is authored and maintained by the Technology Research Institute at Finger, and includes explicit organization and contact details.

2. Purpose and Use Cases

A new “Purpose and Use Cases” section has been added to the specification.

Purpose: Compliance with W3C DID Core and DID Resolution standards, use of a centralized database–based Verifiable Data Registry (VDR), cryptographic signature–based integrity, and provision of a B2B DID-as-a-Service offering.

Use Cases: Enterprise and financial identity management, blockchain integration, SSI and Verifiable Credential scenarios, and API-based authentication.

Target Users: Financial institutions, fintech companies, and blockchain service providers.

3. Centralized Database–Based VDR Clarification

As you noted, the current specification is explicitly defined around a centralized database–based VDR. This assumption is now made clear throughout the document, including the resolution and management APIs and the trust model.

In addition, the GitHub repository README has been updated to reflect the same information.

If possible, I would appreciate it if you could take another look at the updated specification. Please let me know if there are any remaining concerns or additional improvements you would recommend—I would be happy to address them.

Thank you again for your thorough review and helpful guidance.

Best regards,
youngseokaaa

[youngseokaaa]

Hi @swcurran ,

I hope you’re well. I wanted to gently follow up on the did:finger registration PR.

It has been about two weeks since the specification and README were updated. When you have a chance, could you let me know if there are any remaining concerns that need to be addressed before approval?

If everything looks sufficient, I would appreciate your approval.

Thank you again for your time and review.

[youngseokaaa]

Hi all,

I hope you’re doing well. I wanted to gently follow up on this PR and check whether there are any remaining concerns or unresolved points preventing approval/merge.

As far as I understand, all previously raised review comments have been addressed, and one approval has already been provided. Since some time has passed, I just wanted to kindly confirm whether there is anything else I should update or clarify.

cc @MizukiSonoko @gatemezing @swcurran

Thank you very much for your time and review.

[gatemezing]

The proposal meets the minimal requirements for integration

[youngseokaaa]

Thank you very much for your review and approval. I really appreciate your time and feedback.

[youngseokaaa]

@ottomorac @MizukiSonoko @gatemezing

Thank you very much for the reviews and approvals.

It appears that the required approvals have now been received, so I wanted to kindly check whether there are any remaining steps or requirements needed before this PR can be merged.

If everything is in order, I would greatly appreciate moving forward with the merge when convenient.

Thank you again for your time and support throughout the review process.