4G/ Anonymous Claims Authentication

Anonymous Claims Authentication – Requirements and sequences

Thursday 4G

Session Leader: Nat Sakimura, Nomura Research Institute, (@_nat_en)

Notes-taker(s): Nat Sakimura

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Participants: Andrew Hughes, Sarah Squire, John Bradley, Carla Roncato, ..

Abstract

People talk a lot about such concepts like "anonymous", "verifiable claim", "claim authentication", etc. While it is a nice sounding words, it is not clear if they are speaking of the same thing when they use these words. It may as well be talking past each other.

In this session, these concepts were first defined to allow some precise discussion. Then, 12 abstract requirements for "Anonymous Claims Authentication" were built. For clarity, “Anonymous Claims Authentication” means “Claims Authentication in systems where anonymity is desired”. Finally, these requirements were examined against a possible implementation to check that these are indeed achievable.

1. Defining concepts

At the beginning of the session, the following concepts were examined:

- anonymous

- claims authentication / verifiable claim

To define these concepts, the following model was introduced.

The first step is the user registration at the IdP. IdP must verify the claims related to the user upon registration so that it can attest the claims later.

Then the IdP creates claims set re: user (called authenticated identity) by user authenticating the user. Such authenticate identity is presented to the RPs. Such process is depicted in the following figure.

Here, through the user authentication by IdP (Identity Provider, claims issuer. The party that attests that the claims values are accurate to his knowledge), various "sets of claims" called authenticated identities are formed. These authenticated identities are presented to the relying parties, RP, (e.g., web sites, depicted as A and B in the above figure) to access services offered by those relying parties based on the value of the claims included in the authenticated identity. There is a concept of time-lines depicted in the above diagram. When the user visits A at time t, then an authenticated identity denoted IAt is presented. For example, for t=1 and 2, then two distinct authenticated identities, IA1 and IA2 are presented respectively. Similarly, when the user visits B at t, IBt are presented.

Def: Entity-Identity linkable

In a system S, if A can link the user to IAt, then S is said to be entity-identity linkable for A.

Def: Inter—RP linkable

In a system S, if A can find out that IAx and IBy belongs to the same user, then S is said to be Inter-RP linkable.

Def: Inter-temporal linkable

In a system S, if A can find out that IAx and IAy belongs to the same user, then S is said to be inter-temporal linkable.

Then, with these linkability concepts, the participants examined what is meant by pseudonymous and anonymous when we usually refer to them. They agreed that when we say "pseudonymous", we usually mean RP-pseudonymous as follows.

Def: RP-Pseudonymous

If it is not Entity-identity linkable nor Inter-RP linkable, the system S is said to be RP-pseudonymous.

Similarly, when we say "anonymous authentication" etc., the "anonymous" usually is talking about "RP-anonymous" as follows.

Def: RP-Anonymous

If it is not Entity-identity linkable nor Inter-RP linkable nor Inter-temporal linkable by RPs, the system S is said to be RP-anonymous.

Def: IdP-Anonymous

If it is not Entity-identity linkable nor Inter-RP linkable nor Inter-temporal linkable by IdPs, the system S is said to be RP-anonymous.

Then, it was examined if it is possible for the RP to verify or authenticate the claims, i.e., to evaluate that the value is accurate to the desired probability, if S was IdP-Anonymous as well. It was agreed that it is not possible as there would be no party attesting the accuracy of the values of claims anymore.

As the result, the participants agreed that by "anonymous claims authentication" or "anonymous but verifiable claims", we actually mean RP-anonymous authenticated identities (clams set).

2. Requirements for RP-anonymous verifiable claims system

Then, the participants discussed what would be the requirements for RP-anonymous verifiable claims system. We started off from the 8 requirements that Nat prepared beforehand. These are prepared from what he has been hearing as requirements for such systems from various people so it is not using the concept defined above, but the participants mentally translated these in the above terms and verified that they are sensible.

RP MUST not be able to link two authenticated identities.

RP MUST be able to evaluate the level of assurance of the claims received.

IdP MUST be able to authenticate the entity at a required level of assurance.

IdP MUST be able to attest the accuracy of the claims value at a level of assurance.

IdP MUST not be able to determine where the assertion is being presented to.

RP MUST be able to determine if the assertion is forged.

RP MUST request only the minimum necessary claims.

IdP MUST provide only the requested claims.

In addition, the participants came up with the following additional requirements.

Observers MUST NOT be able to link entities to identities (i.e., the system MUST NOT be Entity-Identity Linkable.)

Claims MUST be opaque to observers.

Authenticated Identities MUST BE non-transferable (Collusion resistant)

The system MUST be timing-correlation resistant so that colluding IdP and RP cannot compare the logs to find out retrospectively who went to what RP.

It is probably a good idea to re-state these in terms of the concept defined in the section 1, but as the time was running out and we wanted to join the closing circle, we proceeded to the next task.

3. Reality check – can it be achieved?

Finally, the participants checked if it can be achieved by briefly inspecting the sequence diagram that Nat has prepared, where Proxy in his mind was a self-issued provider so that there is no IdP-Proxy collusion issues. John pointed out that OpenYOLO can also be used. (Note: It is assumed that device finger-printing precautions are taken by the UA. Otherwise it is only RP-pseudonymous at best.)

Participants quickly verified that it seems to be satisfying the requirements 1 to 8.

Requirements 9 and 10 seems to be achievable through channel encryption and request/response encryption.

Requirement 11 can be achieved by setting nonce=token binding ID.

Requirement 12 can be tricky. It probably requires random wait at the proxy as well as large enough traffic to the RP. Alternatively, an operating scheme that ensures IdP-RP collusion can be introduced.

Finally, it was noted especially by John that system like this while often demanded by governments are not really useful. Specifically, the requirement 5 is irrelevant most of the time since the user trusts the IdP. Otherwise, why does the user use IdP?. Sarah pointed out that the free choice is not always available to the user and thus it is important from the government perspective to be able to do this.

To close the meeting, Nat thanked the participants that as an editor of ISO standard related to this topic: ISO/IEC 27551 Requirements for attribute-based unlinkable entity authentication and that this session was very useful for him. Sarah asked what would be the use of such standard and Nat conjectured that perhaps vendors could self-attest or third party attested that they are compliant to such a standard. Participants agreed that it would be a good opportunity for an identity professional to get a revenue opportunity.