353 VIEWS
Pinterest LinkedIn LINE

Twitter jirok 縦割りスパゲッティの情報基盤整理しようとしてるのですが、「 ...

Professor Kokuryo, whom I deeply respect, gave me this topic. It took a little time, but I have now put my thoughts together in this blog post.

Let me begin with the conclusion.

(1) Identifier → Identity Register+RA

(2) Identity verification infrastructure → IdP+CSP

(3) Attributes → IIA/IIP

(4) Services → RP/SP

If we reinterpret the categories this way, it appears best to divide and separately manage them in this manner.

The explanation follows.

The foundation of IdM is identifying the user in question. Identification means uniquely distinguishing an entity from all other entities in a population. Because we cannot directly observe an entity, this amounts to collecting values of attributes associated with that entity until their set becomes unique. In this state, the set of attribute values serves as the “identifier.” However, values may continually change and may cease to be distinguishing at another point in time, so management becomes difficult unless a unique and immutable string is assigned at the time of identification. ISO/IEC 24760-1 calls an identifier assigned for this purpose a reference identifier, and calls the function that creates it a reference identifier generator.

Because attribute values are used for identification, the reliability of that identification depends on the reliability of the attribute values. Measuring the reliability of this set of attribute values is called Identity Proofing. Since Identity is defined as a set of attributes related to an entity, Identity Proofing means “verifying a set of attributes related to an entity.” What Japan calls “identity verification” can basically be regarded as a special case of this, in which the attributes are the 4 basic pieces of information. ISO/IEC 29115 proposes dividing the confidence level of the values in this set of attributes into 4 levels.

Identity management (IdM) manages the identity of an identified entity. To do so, it is recorded in a registry called an Identity Register. The person who performs Identity Proofing and records someone in the Identity Register is called the Registration Authority (RA).

Identity has a lifecycle. ISO/IEC 24760-1 proposes managing the lifecycle in 5 phases: unknown, established, active, suspended, and archived.

For an entity identified in this way to use an online service, the person creates and uses an online identity to represent them. Only the person concerned must be able to create this identity, and others must be able to verify that the person controls it. The information used to ensure that only the person concerned can create it is called a “credential.” It is something that only that person can produce. A password is a representative example. The person presents this credential to a mechanism called a “verifier” or “Credential Service Provider (CSP)” and proves that the person currently present is indeed them. This is called Authentication. An identity created through this authentication, which others can verify is controlled by the person concerned, is called an Authenticated Identity.

The reliability of this Authenticated Identity depends on the reliability of the credential used. That reliability, in turn, depends on how reliably the credential is managed throughout its lifecycle, from issuance, delivery, activation, and use through suspension and deletion. The reliability of the resulting Authenticated Identity is the reliability of the attributes it contains (the fact that authentication was performed using a credential is itself one attribute). It therefore depends both on the reliability of the attributes verified through Identity Proofing and on the reliability of the credential.

Meanwhile, there are many attributes beyond those used for identification. An Identity Register also stores attributes, but its scope is limited to those required for Identity Proofing. Although operations that put everything else into it as well are often seen, this is not necessary, and independent attribute providers can be envisioned. ISO/IEC 24760-1 calls such an entity an Identity Information Provider (IIP). In general, the name Attribute Provider is more commonly used. An IIP capable of providing authoritative information is called an Identity Information Authority (IIA). From the perspective of information freshness and accuracy, information should always be obtained from the IIA. However, doing so reveals to the IIA where that information was submitted, so information is sometimes deliberately obtained through another IIP to avoid this. The decision here involves balancing privacy against information accuracy. Note that an organization that creates and provides an Authenticated Identity is also a type of IIP. In the industry, this kind of IIP is often called an IdP.

Also note that an Identity Register can exist entirely independently of credentials or the creation of Authenticated Identities through authentication by the person concerned. A customer database, for example, is a typical Identity Register. Its management also falls within identity management in the broad sense.

Meanwhile, some parties use the Authenticated Identities created in this way. Because they rely on identity information from another party, they are called Relying Parties (RPs). When attention is instead focused on their provision of services to the person concerned or to third parties, they are also called Service Providers (SPs). Before using a received Authenticated Identity, an RP verifies its reliability and validity through signatures or other means.

A protocol for exchanging information requests and responses between an IIP and an RP is called an Identity Federation Protocol. OpenID Connect, whose specification development I worked on, is a representative example of an Identity Federation Protocol. With OpenID Connect, the minimum necessary attribute information is requested each time and made available to the RP with the person’s permission.

We now have all the functions needed for identity management and federation. (This is a rough overview. More precisely, there are also PDPs, PEPs, and various other elements, but let us leave those for another occasion.) The question is how these functions should be arranged. There are perspectives of efficiency, security, and privacy; here, I would like to consider the privacy perspective.

What are commonly called “privacy principles” summarize the considerations that apply from the privacy perspective. The OECD’s 8 principles and the U.S. FIPPs are well known, but here I would like to use the principles of ISO/IEC 29100.

ISO/IEC 29100 has the following 11 principles.

1. Consent and choice
2. Purpose legitimacy and specification
3. Collection limitation
4. Data minimization
5. Use, retention, and disclosure limitation
6. Accuracy and quality
7. Openness, transparency, and notice
8. Individual participation and access
9. Accountability
10. Information security
11. Privacy compliance

Of these, the ones related to arrangement are 3. Collection limitation, 5. Use, retention, and disclosure limitation, and 6. Accuracy and quality.

“3. Collection limitation” requires that no more information be collected than the minimum necessary to perform the relevant operation. To comply with this, it would be inappropriate to collect in the Identity Register any information beyond what is required for registration. The Identity Register and other IIPs should therefore be kept independent. A reference identifier generator and an Identity Register can also be managed separately, but because the reference identifier will be placed in the Identity Register in any case, operation by the same organization would be more efficient. On the other hand, a Registration Authority (RA), which performs Identity Proofing and records the result in the Identity Register, is often operated by a different organization from the Identity Register. Where the Identity Register stores only some of the information used for Identity Proofing, separation appears preferable under the collection limitation principle. Considering the Identity Lifecycle, however, the Identity Register and RA must be operated in very close coordination. If this close relationship is not maintained, unintended disclosure and other privacy risks can be expected to increase. In view of these considerations, I personally think it is acceptable to operate the RA and Identity Register as an integrated unit.

“5. Use, retention, and disclosure limitation” states that data must be used only for the purposes authorized when it was obtained, retained only to the extent necessary, and disclosed only within the scope of consent received. This means that data must be managed in association with its purpose of use and the relevant consent. Viewed this way, managing data obtained for different purposes together in one mixed pool is quite difficult. RPs should therefore not be consolidated indiscriminately, but should be divided and managed so that the management burden does not become excessive.

Finally, there is “6. Accuracy and quality.” To the extent operationally feasible, information should be obtained from the IIA in real time. This is another reason not to collect information indiscriminately at the IdP. It follows that attributes should be managed separately by each IIA.

The CSP is the remaining element. Operating a CSP as an integrated unit with the Identity Register is entirely conceivable. As for the privacy impact in that case, none of great significance immediately comes to mind. On the other hand, separation is also entirely possible from the standpoint of flexibility. If separated, an Identity Register could use multiple CSPs, and a CSP could provide services to multiple Identity Registers.

And so, at last, here is the answer to the question.

(1) Identifier → Identity Register+RA

(2) Identity verification infrastructure → IdP+CSP

(3) Attributes → IIA/IIP

(4) Services → RP/SP

If we reinterpret the categories this way, it appears best to divide and separately manage them in this manner.

Related posts