Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
A good alignment, though not yet a grand unification (2007/2/6)
Numerous recent announcements of the partnership between Microsoft and some of the OpenID developers for a closer relationship between InfoCard/CardSpace and OpenID have indicated a promise of improved interoperability, and an enlargement in the ranges of potential deployment scenarios for implementations of each protocol suite.
One of the interesting aspects in this relationship is desire, as part of InfoCard's anti-phishing strategy, to provide some manner of quality-of-authentication metric from an identity provider (IdP in CardSpace or OP in OpenID) to a relying party (RP), in order that relying parties may better be able to recognize when phishing resistant credentials have been provided by the user.
Looking forward, I see this as one attribute of a transaction between an IdP and an RP, and an indication of "the kinds of authentication which an IdP can perform" as an attribute of a relationship between an IdP and an RP.
Now typically in identity discussions, the concepts of relationships is typically taken in the context of
the association between one individual to another,
as in social networking systems, or
the association between an individual and an organization,
as in customer and vendor relationship management.
However, many other categories of relationships exist in identity systems and could impact the long-term deployability of both InfoCard and OpenID-based federations.
In particular, one open question for systems based on InfoCard protocols, OpenID protocols, or a hybrid of both, is
How is the relationship between an Identity Provider (IDP) an a Relying Party (RP) established and maintained?
At present, the answers seem to be 'out of band business processes' and 'manual updates'. As I mentioned last year, the protocols for communication between an InfoCard IdP and RP are currently underspecified.
Currently, in the published InfoCard specifications, relying parties security token services (STS) and applications can advertise their policy constraints on acceptable tokens and issuers via the WS-Policy protocol. At present, I have not yet seen a standard way for OpenID or InfoCard Identity Providers to advertise their capabilities. In particular, how should a relying party determine what identity provider are trustable is still determined on a case-by-case basis.
In a closed community in which a relying party only trusts the validation of credentials to be performed by a single identity provider, typically run by that same organization, then this is a non-issue. Other environments, such as in a federal government medium security infrastructure, a relying party may have an enumerated set of identity providers that it recognizes. In other environments, it is not clear how a relying party should choose the identity providers that it trusts. If RP 2 trusts IdP 2 and IdP 3, should RP 2 also trust IdP N?
- One potential way for the RP to choose is to have a manually-maintained list of IdPs, and add IdPs to this list based on customer demand. This has a limitation that long tail users who use minority but trustable IdPs may be rejected by the RP.
- Another way would be for a RP to trust any IdP that has a certificate issued by a CA for which the RP has a trust path to one of its preconfigured root CA set. Of course, as certificates are easy to get, anyone can become an IdP, and the RP has no way of knowing whether one IdP's policies are acceptable to the level of identity assurance needed by the RP.
- A third potential way would be for the CAs to define new certificate extensions that indicate the certified subject is an organization that has performed a validated level of identity assurance. This indirects the problem by outsourcing the decision to one of a set of CAs, which might be valuable when there is broad consensus on the kind of authentication and identity assurance required (e.g., for federal government interactions), but would lock out small communities in which the users have means of trusting an IdP that are viable for interactions amongst themselves, but are not necessary scalable to national or international contexts.
- A fourth way would be that there could be some form of external system that assists an RP in determining whether an IdP should be trusted. This could be driven by published statements made by the IdP, as well as that IdP's reputation as reported by its users and other RPs.
Once this IdP-RP relationship is established, in the existing InfoCard protocols, some of the transactions between these parties are overloaded on the SSL certificates and the enveloped public keys that these parties' web applications and web services provide for HTTPS. The loss or potential exposure of one of the parties private keys can be made aware to other parties through certificate revocation lists and protocols such as OCSP, but non-emergency behavior may not be as well handled. When these parties perform their regular key change or certificate renewal, or change from one certificate issuer to another, the RPs which have hardcoded existing keys and certificates may suddenly fail. An operational protocol which allows a IdP to provide notification and negotiate these handovers with the RPs it services would be desirable, however at present, IdPs may not even be aware of the RPs that are relying on it, and have no means of determining whether a particular RP should be relying on it.
It will be interesting to see what can be leveraged from the experience of traditional federated identity systems, based on Project Liberty, or from the emerging recent Liberty and WS-Federation specifications.