At IIW in May, we think we heard a call for people to submit their requirements towards the development of the next version of OpenID specifications. This email is intended to contribute some requirements from the British Columbia Government.
At this time, BC Gov goes not specifically promote the use of OpenID like the US ICAM profiles, however we are watching what you're up to, and will consider the v.Next protocol for our future. We are pleased to see the new and continued efforts to tackle the tough issues surrounding this. In BC, we have an emphasis on and advocate federated identity approaches that will enable governments to put higher valued services online for our citizens and businesses. At this time, OpenID 2.0 does not meet those objectives. Check out this recent blog post about BC Gov's lack of support for OpenID and how our CIO Dave Nikolejsin defended our position, and even Dick Hardt chimed in: http://eaves.ca/2010/05/31/canadian-governments-how-to-waste-millions-on line-30m-and-counting/ To summarize what I propose below, we need federated approaches meet the requirements of - using various identity assurance frameworks (Canada and BC have our own "LOA" frameworks) - supporting identity attribute exchange - using multiple parties for authentication and attributes Furthermore, we think that these requirements are similar to what other governments need. We may have different frameworks and policies, different rules about identity attributes, and different technical architectures. It would be great to have a federated approach that is flexible enough for us to use in such an environment. BC Gov also worked on requirements for an overall identity metasystem, through a forum of identity industry experts back in 2007. This work is published at http://www.cio.gov.bc.ca/cio/idim/idm_forum.page. Even though this work presumes an identity agent, many of the requirements are still relevant to a non-identity agent model. Requirements from BC Government towards an improved OpenID protocol The following are general requirements to satisfy both a federated approach to authentication and the corresponding exchange of identity attributes. It is presumed that such a protocol, in its simplest case, would involve a request from the relying party to an identity provider, and a response from an identity provider to a relying party that satisfies the request. The following emphasizes the requirements of a protocol that supports a scalable, flexible and extensible model. It describes the use of parameters within the protocol to achieve security and privacy related policies. It does not describe requirements for user experience or passive/active support - but yes, we need all of that too. And yes, I realize that some of these requirements sound like "other" federation protocols. Requirements for the request: a) The request must allow the relying party to indicate one or more specific policies related to requirements for authentication methods, levels of identity assurance or other similar security or privacy policies. b) The request must allow the relying party to indicate one or more specific attributes, the corresponding attribute values or a range of values that are expected to be sent, and the level of verification and potentially other metadata about the attributes. These may be identity related attributes or other contextual attributes, such as a request for the disclosure of the authentication method that was used by the identity provider. c) The request must allow the relying party to indicate the type of token (or allowable types of tokens) that it can accept within the response. d) The request must allow the relying party to indicate the security policy to be applied to the response or token in the response, such as whether and how to use encryption or digital signing within the token, or whether and how to send the response over TLS. e) The request must allow the relying party to identify itself in a secure manner, to allow the identity provider to optionally verify the relying party before proceeding with the request. Similarly, the request must allow the relying party to not identify itself, to allow the identity provider to act without regard to or disclosure of the relying party. f) The request must be able to fully contain all parameters of the request such that the identity provider can act on the request without needing to have an out-of-band configuration about the relying party. Requirements for the response: g) The response should conform to the request from the relying party, and contain a restatement of the policies that were applied from the request. h) The response must contain one or more tokens that contain the specific attributes requested. i) The response must allow the identity provider to identify itself in a secure manner, to allow the relying party to optionally verify the identity provider before accepting the response. General requirements: j) For any of the above request parameters, the parameter should be allowed to be left unspecified, in which case the identity provider can determine what to do; be specified using industry-standardized values, or be specified using custom values so that a relying party and identity provider can create their own extensions. k) The request parameters should be specified with a richer language, instead of specifying the specific parameters as a strict set of values, to allow for extensibility and more complexity. l) The protocol should facilitate multiple identity providers to be used to satisfy a relying party's requirements. Two common examples are i) when one identity provider handles the authentication event and another identity provider supplies identity attributes; and ii) when one identity provider handles the authentication event and some identity attributes, and another identity provider supplies additional identity attributes. In these cases, context and attributes need to be passed from one identity provider to another. m) The protocol should include an extension for how an identity provider should publish its capabilities (authentication methods and other security policies that it can perform, and which attributes it can supply), so that a relying party can determine whether the identity provider is capable of meeting its requirements. n) The protocol should be written such that different industries or communities can write profiles of it to satisfy their need to write standards that meet their specific requirements for policies and attribute exchanges. Patricia Wiebe Senior Identity Architect, Architecture & Standards Branch Office of the Chief Information Officer, Province of BC Phone: 250.387.6818 Mobile: 250.514.7685 Email: [email protected]
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
