BC Government requirements for OpenID v.Next

Wiebe, Patricia CITZ:EX Patricia.Wiebe at gov.bc.ca
Tue Jun 8 19:45:21 UTC 2010


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:  Patricia.Wiebe at gov.bc.ca


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100608/e0c7734c/attachment.html>


More information about the specs mailing list