Frequently Asked Questions
Identity conflicts are resolved at the time a Digital Address is created. In case of a conflict, there is a conflict resolution process which involves the parties — issuers, users, and digital address providers.
A user has one Digital Address and may have multiple DIDs, such as for various credential presentations.
Service providers use GADI to verify user identity, but are not able to access usage patterns by design.
No user data is collected by the DAP. A DAP is a utility for providing credential verification.
GADI stands for Global Architecture for Digital Identity.
GADI provides a way to create a trust anchor and bootstrap a trusted identity for use in a trusted identity ecosystem.
Systems in the GADI ecosystem often rely on technologies that are also used by SSI platforms, and those SSI platforms are also able to participate in the GADI ecosystem, but GADI itself is not SSI.
GADI is Issuer and User focused. We are using W3C interoperable standards. The users owns their identity.
We have started talking to various agencies and interest levels are good. There are many components of GADI that come from other bodies that already have buy-in from government agencies (W3C, etc.) More deliberate outreach will begin after the first specification is released.
Yes. There is no need to replace anything. It’s easy for existing identity systems to embrace the GADI ecosystem. GADI interoperates with systems in place and provides secure privacy-enhacing identity vetting that benefits the consumers and enhances trust in digital transactions.
DAPs and GADI are DLT-agnostic.
GADI is working with available solutions that address multi-users on the device.
The governance framework is still being developed. GADI will be managed by a neutral body elected by DID Alliance membership.
Issuers benefit by joining the value chain for identity verification and also help prevent identity fraud at the same time. Additionally they may mitigate costs for their own KYC processes.
At a high level, that is done using a kiosk type of application. A kiosk can accept the DA from a card or from a user typed DA (plus PIN) and the kiosk application will navigate the user.
GADI incorporates multiple methods to bind the user to the credential and to ensure user-consent. This methodology will be defined in the specification which is being developed now, and we welcome contributors.
We are using the standards that they are developing and we will continue to use them. We don’t believe in reinveting wheels. There is much that is being done in DIF that is specifically useful in the trust framework that GADI provides.
This is one of the most important considerations to make when you want to operate at a global scale. There will be a certification process. Issuers are brought onto the ecosystem by DAPs. DAPs are required to follow the governance framework of GADI when they bring Issuers on the ecosystem and the issuers will have to meet requirements of the governance framework in order to be certified.
There are different ways to do that, starting from having the current device bootstraping additional devices with consent from the first device and the DAP acting as a facilitator, or it can be a recovery process using a key that is generated from a user biometric that can be used as the service handle between the user and the DAP, or some other ways that a DAP chooses to offer. This is one of the issues being developed by the Technical Working Group.
GADI is not an SSI solution, although we are aligned on some of the principles of SSI — specifically the user having control of their data and providing consent to share presentations of verifiable credentials. It is about creating a Digital Address which has a unique trust anchor and using that to make the user’s life easier and also to include the population that is not technologically savvy or people without smart phones.
It is possible to issue a Digital Address to an organization and then certain types of verifiable credentials based on the attributes of the organization can also be managed through the organization’s Digital Address.
We know this is needed, but unfortunately, more education and socialization is needed.
We use a lot of the work that has been done at DIF, W3C VC, etc. As mentioned, we are about bootstrapping the ecosystem with existing ID systems and providing Trust and Accountability, without replacing existing infrastructure and rewriting the applications.
There are the initial patents as well as documents managed by the Technical Working group. The specification is still being developed. We invite interested parties to join the DID Alliance and participate in the Technical Working group to contribute to the specification.
Governments can play a role of being an initial Trusted Issuer and can create the Digital Address to bring a user onboard to the ecosystem. Governments can also use this system in the role of Service Provider, too. Use cases such as providing social benefits, collecting taxes, etc. The system helps to bring fraud down to practically nil. Financial Institutions are also natural Issuers, as they do a lot of identity vetting before opening an account for or giving a loan to a person. Financial institutions will also be Service Providers who can use the GADI system for peer to peer payments, micropayments, etc. with strong assurance levels.
There are different ways to do that, starting from having the current device bootstrapping additional devices with consent from the first device and the DAP acting as a facilitator, or it can be a recovery process using a key that is generated from a user biometric that can be used as the service handle between the user and the DAP, or some other ways that a DAP chooses to offer. This is one of the issues being developed by the Technical Working Group.
GADI is not currently used for a live identity system. The specification is still in development. The demo is the reference implementation of the architecture which helps to inform the finalization of the specification. We encourage all to join the Alliance Technical Working Group and contribute.
The GADI infrastructure does not reuse identity attributes itself (nor do the DAPs). User attributes in this model stay with and come from the Issuers by way of an agent. The user has handles / controls for those attributes. When a Service Providers needs to check an attribute, the User simply presents a verifiable credential presentation that meets the requirements for the verification. A DAP does not hold any identity data.
There is no upper limit to certified Issuers in the GADI ecosystem. In order to join the ecosystem as an Issuer, there is a certification process.
GADI is not currently live. The specification is still in development. We encourage all to join the Alliance and contribute.
GADI will likely not take that long, as there are already global efforts to address the digital identity problem, and every country is looking toward Citizen Identities; every DMV, every passport office, every university, every hospital is trying to issue digital credentials. However, all are evolving as silos and without a global context. One can not separate Identity and PII — they are tightly bound, and should be treated that way. GADI addresses the issue holistically, and can be bolted onto existing identity systems and provides a way for those identity systems to publish user credentials and have user consent to credential presentation disclosures. Hopefully it does not take as much time, as it the fits into the current efforts from various players.
GADI is not federation. It merely helps to connect existing identity systems into a greater “Distributed Identity Ecosystem”
Yes. The GADI ledger itself uses DLT.
If transactions at multiple providers are linked to a single identifier, those transactions can be linked by that identifer regardless of whether GADI is involved in the transaction or not. The issuer/service provider simply records the digital address, then uses it to link that transaction to other transactions from other service providers. Someone will set up that business.
The demo example we showed in the video, where a moniker for the Digital Address is typed, is just one way, we use it to emphasize the simplicity of using a Digital Address. There are different ways to stop the correlation you mention. For example, the service provider side interface may simply make a credential request via QR Code, which would be a one-time transaction the user can use to provide proof. Or the user’s mobile DA app may request the DAP for a one-time identifier that the service provider can use to request the credential; there are a couple of other models that are being discussed in the TWG, and anyone is welcome to participate / contribute to guide this work. Further, none of these things work if there is no proper governance or policyframe work backed up by a legal framework. GADI certification needs to make sure the certification process includes checks and balances to avoid service provider collusion. We also would like to clarify that GADI is “Global Architecture for Digital Identity”, not “Decentralized Identity.” The distinction should be kept in mind. Our Core Focus is to make sure –
1. Issuers will have easy way to push the VCs to users easily.
2. Users have a very easy way to interact with the ecosystem.
3. Issuers included in the value chain.
4. Include everyone, not just people who have a smartphone.
5. Make sure there is a trust Framework where Issuers are trusted to issue credentials” and Identities have a human binding with FIDO.
6. Issuers and users can be trusted across all member networks wherever they are.
Yes, the idea is to bring Issuers into the value chain. By enabling cross-ledger payments, it will allow for the micropayments and payments across the various identity systems.
Certain types of credentials could be made available in an offline format, but for most credentials involving identity, it would be necessary to verify against revocation which requires an active connection.
GADI will likely use some of the binding work that FIDO is doing and apply it to the concept of bootstrapping the user during onboarding at the time of DA creation.