The Properties of Identity

Identity behaves according to a number of observable properties, as follows:

Improvement suggestions for the Austrian Citizen Card

The Austrian Citizen Card has quite advanced security and privacy concepts, but failed to achieve success in the 10 years of its existence.   The attached documents analyzes the reasons for the problems and how the strategy would need to be improved to achieve market adoption.

Simplified SLO (v0.2)

The Austrian Portalverbund never managed to implement a Single Logout (SLO) protocol, mainly because of the known difficulties with usability. However, logout procedures required by security policies need to be obeyed, and closing the browser for logout is difficult to enforce. This was less a problem in the current reverse proxy architecture, but with the migration to the SAML Web SSO it will become an issue.

Trust relationships and scalability

Thesis: Systems grow reasonable well as long as capacities scale in a linear fashion. If a network requires pairwise activity to set up legal or technical trust relationships, then a party will be a bottleneck if the capacity to handle additional contracts is exceeded.

Is expressing Levels enough for LoA2+?

Nat Sakimura writes  that Level of Assurance 2 is not good enough to the Relying Party, because the RP cannot assess the risk associated with the particular authentication. A form of explicit liability should be added to enable automated hence scalable contract negotiation possible. 

I agree to the idea of a liability limit, but with some consideration:

Scope and Structure of Authentication Assurance Levels

The trust requirements in electronic communication involving multiple independent parties need to be standardized to allow secure many-to-many trust relationships. In fact, to allow for good scalability, policies and capabilities must be negotiated automatically. The different contributors to this field have overlapping, but different scope definitions for their various policies and frameworks. To give a quick introduction, see following incomplete 

Scope comparison of Identity vs. Trust Federation

To map and compare the scope of federation frameworks I wrote up this set of trust relationships. The terminology is primarily a mix from Kantara Initiative and OIX. The starting point was a review of the Kantara Identity Assurance Framework, that is focused quite clearly on Entity Authentication Assurance (#1 in the requirements list). In the list/picture below I try to show the additional relationships that are not addressed. So items 1 and 6 are part of the IAF, but not the rest.

Why attribute and identity providers need to be separate roles

A typical configuration of an IdP is to authenticate users against a directory that contains both credentials and attributes of users. The organization operating the IdP is responsible for maintaining the directory. It it obvious to assert both the user's identity and her attributes at the same time.
However, there are use cases that need different models:

Syndicate content