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