Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
The Trust is Out There: Do we need practice statements for OpenID Identity Providers?
(2007/2/21)
One difficulty I encounter when glancing through the wiki listing of public OpenID providers is that while in the OpenID model there are multiple parties interacting with an OpenID identity provider (OP), only one kind of party seems to be obviously addressed on the public OpenID providers' web pages: the end user.
If the viewer of the OP site is an end user trying to decide among the providers, then the user appears to have two types of information available to them: (1) the URL of the identity provider, and (2) the "self-asserted marketing claims" on the OP's page, terms such as
- "anonymous"
- "custom identity profile"
- "domain with you in it"
- "ease of use and nice design"
- "first server in REGION"
- "first server in REGION"
- "first server in REGION"
- "first server in REGION"
- "free"
- "free"
- "free"
- "free"
- "free"
- "free"
- "free"
- "free"
- "free"
- "free"
- "free"
- "free"
- "happier Internet experience"
- "it probably contains lots of bugs but *should* be usable"
- "it's FREE"
etc.
If, however, the viewer of the OP site is a representative of a relying party (RP) trying to decide whether to add the provider to its trust set, the above list doesn't seem to be particularly helpful. What an RP wants to know about an OP is it's policies, procedures, reputation...
Some information is included in the OpenID Assertion Quality Extension 1.0 - Draft 3: did the OP verify liveness, did the OP verify the user had an email address or telephone number; what authentication methods (smartcards, biometrics etc) does the OP support for a particular user.
Even for an emerging OP, there is a larger useful set of information which a OP could provide to both end users and RPs to make this evaluation process easier, and as it happens, there's already a well-defined template for this description.
During the 1990s a significant collaborative effort between representatives of the worlds of technology, law, and government was focussed on establishing a framework for a public key infrastructure to be able to support commercial and government transactions. One of the many results of this activity was a document Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, last published as RFC 3647 in 2003:
"This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement."
By analogy with this document, one can imagine the following definitions, transliterated from the world of certificates into OpenID language:
OpenID Policy - A named set of rules that indicates the applicability of an OpenID to a particular community and/or class of application with common security requirements. For example, a particular OpenID Policy might indicate applicability of a type of OpenID to the authentication of parties engaging in transactions for the trading of goods or services within a given price range.
Ideally, a small set of OpenID Policies that represent the applicabilities of OpenIDs issued by many of the OpenID identity providers could be agreed and published. If an OpenID identity provider lists the OpenID Policies for which it issued OpenIDs, both end users and relying parties could use this to quickly determine whether a particular OpenID identity provider is suitable for their intended use.
Each OpenID Policy would have its own URI, and the URIs identifying the OpenID Policies governing the use of a particular OpenID could be an attribute of that OpenID, and be provided to a relying party. The relying party could use this information to differentiate between different classes of OpenIDs issued by an identity provider trusted by that relying party.
OpenID Enrollment Practice Statement (OEPS) - A statement of the practices that an Identity Provider (OP) employs in issuing and managing OpenIDs for End Users.
If an OpenID Policy specifies the WHAT, the OEPS describes the HOW. Each OpenID identity provider would likely have a unique OEPS.
An OEPS might contain a list of OpenID Policies supported by that OP, and for each, include "a set of provisions that contains statements responding to that policy by filling in details not stipulated in that policy or expressly left to the discretion of the OP", that state how the OP implements the requirements of that OpenID Policy. It might also contain statements of the enrollment and management practices of the OP, regardless of any particular OpenID Policy.
This OEPS is of particular interest to a relying party to determine whether to add the identity provider to its trusted provider set. If there is a contractual relationship between the identity provider and the relying party, this OEPS might be referenced in the contract.
Sections 4 and 6 of RFC 3647 give a recommended outline of a certificate practice statement, of which the major areas are:
1. Introduction
2. Publication and Repository
3. Identification and Authentication
4. Certificate Life-Cycle Operational Requirements
5. Facilities, Management, and Operational Controls
6. Technical Security Controls
7. Certificate, CRL, and OCSP Profile
8. Compliance audit
9. Other Business and Legal Matters
It would be an interesting exercise to map the full outline of topic areas into OpenID concepts, and a similar process could also be followed for mapping into the InfoCard metasystem concepts. Potentially a common subset of enrollment, operational and business/legal topics of consideration could be identified, so that this subset is applicable to consideration in any of the PKI-based, federated and user-centric identity management environments.