1. Requirements List
1.1. ADIA Requirements
We will likely remove this section later. But for now let’s keep it as a reference for the requirements th specs needs to meet.
| No | Goal | Rationale |
|---|---|---|
| 1 | The ADIA Framework respects national laws and allows the DASs to operate according to their local regulations. This includes compliance to CCPA and GDPR. | Local law is the basis for any business. |
| 2 | Users must have control on user credentials, i.e. no credentials are created or shared without the user’s consent. This means, DAS asks for user consent and strongly authenticates the user. | Data Privacy regulation & expectation |
| 3 | Users have the ability to select a set of attributes verified by a specific issuer to be included in a specific credential. | Data Privacy regulation & expectation. If the user only wants to share a subset of the data that should be ok to the issuer. |
| 4 |
ADIA doesn’t make user tracking or collusion between Service Providers easier.
If two SPs both received a credential that John Doe was born on date X in Y,
then the two SPs could learn it is the very likely same user. But this has nothing to do with ADIA.
As a consequence, the Digital Address / Trust Anchor are NOT part of the credential. Credentials are in the W3C VC format [vc-data-model] and are tied to a DID. | ADIA doesn’t share correlation handles with SPs for privacy reasons. |
| 5 | People who are not smartphone users must be part of the new Digital Identity ecosystem. | A substantial part of the world’s population belongs to this category. This part is key for future growth opportunities |
| 6 | Issuers must be in the value chain. This means that users cannot share credentials issued by an issuer without allowing financial compensation for the issuer. | This is one of the main ADIA benefits compared to other approaches. |
| 7 | ADIA enables a push model from the issuers where when there is change in credential status, latest credential information is what would be presented. | |
| 8 | Issuers should be able to issue the credentials to users who are not part of the same network, i.e. who got their Trust Anchor from a different Digital Address Provider (DAS) than the one this issuer is primarily using. | |
| 9 | There should be cross ledger value settlements for the issuers and may be some reward points for the issuers as Users assert their credentials and provide data. | |
| 10 | Onboard the user with a trusted Identity that is approved by an Issuer after proper Identity vetting | |
| 11 |
It is possible for users to start their participation
based on a low level identity assertion and increase
that level over time.
However, there is a minmum identity assertion specified by the ADIA Governance Group. We need this to prevent user impersonation attacks through weak ID proofing methods. | Many users don’t have connections to a SP which has performed strong ID proofing today. But that might change over time. We need to support such users. |
| 12 | Each DAS provides one Single Digital Address Application for the user to be able to access and control the Identity and Credentials with a Digital Address Provider acting as a custodian interface to interchange the user credentials on demand with user consent. | |
| 13 | Digital Address (DA) is a Human readable string that is easy to use, that is associated with the Users Trust Anchor. This becomes that identifier that the user can provide to issuers to get the credentials issued. | |
| 14 | Users in this scenario will have a single Digital Address Application from one Digital Address Provider and the user will be able to present this human readable, typable, or presentable to the issuers to be able to push the credentials for the user. This is just between users and Issuers. We however can also provide different handles (Different Digital Addresses) that can be orchestrated between the user Device and DAS to present to different issuers if we need to also make DA one time as the issued credential is a DID. | |
| 15 | The ADIA ledger is accessible to DASs only. | |
| 16 | Trust Anchors are generated randomly by the HomeDAS, such that collisions do not practically occur. See Trust Anchor Discussion below. (not clear, see 20) | So that we only need to delete the relation between the Trust Anchor and any other PII when the user asks for account deletion (removal from ADIA). |
| 17 |
Credentials that do not include PII shall be supported. For example "the holder of the credential is at least 21 years old"
or "the holder of this credential got vaccinated against X".
Note: sometimes there are existing business processes which will convey PI/PII outside of ADIA. | In the physical world we have those and for privacy reasons we should carry them over to the digital world. |
| 18 |
ADIA and DASs do NOT persistently store personal information (PI).
And even pass-through of PI should be avoided.
Note: they will likely need to store PII, i.e. information related to users Note: Issuers will have to store PI (in order to be able to issue credentials) | |
| 19 | ADIA will store the HomeDAS Identifier (i.e. HomeDAS_ID) along with the user’s Trust Anchor. So each DAS could ask ADIA for the HomeDAS of a given user and would then directly talk to the user’s HomeDAS. | We need that for cross-DAS communications |
| 20 | We compute a Hash(firstname, last name, date of birth, country+city of birth) as either use this as Trust Anchor or as an attribute stored along with the Trust Anchor in ADIA. | |
| 21 | It shall be possible to change the HomeDAS of a user (e.g. from DAS1 to DAS2). | |
| 22 | Issuers shouldn’t learn the SP that verifies a credential. | Privacy |
| 23 | SPs want to verify the VC and hence will need to decide whether they want to trust a specific Issuer. As a consequence, the SP will learn who the Issuer of that VC is. | |
| 24 |
Need to specify what functionality/certification is needed to call an application a ADIA "Digital Address Application". | |
| 25 | Organizational participants, including issuers, verifiers, and service providers require a publicly resolvable DID | |
| 26 | Regional directory services include the User related information, the global directory only includes information on issuers, service providers abd interchanges. So compliance can be managed on a regional level. | |
| 27 | Logically, the DAA is provided by The Agency - not the Issuer. However, the Issuer could still provide the DAA on behalf of The Agency. |