Hi Patricia, I am from Japan, and I think I am working on a set of similar requirement. Much of my daytime work is with the Japanese government as well. No wonder Artifact Binding (AB) that I, together with John Bradley (who has been working with the U.S. ICAM SC) etc. , am working on seem to fulfill lots of the requirements.
My comments inline: On Wed, Jun 9, 2010 at 4:45 AM, Wiebe, Patricia CITZ:EX < [email protected]> wrote: > 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-online-30m-and-counting/ > *<http://eaves.ca/2010/05/31/canadian-governments-how-to-waste-millions-online-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*<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. > > PAPE extension seems to allow it. > > > 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. > > AX extension seems to allow it, though you would have to define the "verification level" as a parameter as well. > > > 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. > > I suppose you are not using "token" in the sense of SP800-63. If it is, then PAPE can do it. If the "token" means "types of assertion", AB defines a variable called "atype" in the request to allow the RP define it. > > > 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. > > RP may specify the digital signature and encryption method through AB request. AB requires TLS. There is no option for "plain text". I think that is reasonable. > > > 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. > > AB has two ways for the RP to identify itself. The primary and recommended means it to do it through the digital signature (RSA) that is applied to the direct assertion request. It allows us to achieve the non-repudiation of the request as well. The other way, which is slightly simpler, is for the RP to send shared secret to the IdP. It does not provide the non-repudiation. > > > 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. > > OpenID in general, including AB, fulfills it. > > > 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. > > PAPE allows us to do it. > > > h) The response must contain one or more tokens that contain the > specific attributes requested. > AX fulfills it. > 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. > > Since AB requires the direct assertion request to be over TLS, the RP can verify the IdP's identity at that level. In addition, in AB, the IdP digitally signs the response (RSA-SHA256) when required by the relying party. It provides another layer of identification, and non-repudiation as well. > > > 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. > > I am not fully grasping this requirement. Could you kindly explain it a little more? > > > 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. > > I am not sure if I grasped the requirement completely, but if you mean that relying party should be able to specify the set of required attributes etc. flexibly, AX seems to handle it. > > > 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. > > This is exactly what I am dealing with AB and Contract Exchange (CX). For a brief description of them, you can look at: http://bitbucket.org/openid/ab/wiki/Home AND http://public.iwork.com/document/?a=p275492430&d=ABC_of_OpenID-AB.key The second one was presented at the OpenID Summit EU by John Bradley yesterday. > > > 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. > > It is the job of XRDS for public data. >From the privacy perspective, it is undesirable to publish where the person's attribute can be obtained before authorizing the relying party, because it may reveal some of my privacy. For example, if it is published that my work related data can be obtained from https://data.nri.co.jp/, then the viewer may infer that I am employed by NRI. Thus, in AB (and CX), the in the first step, only the IdP is identified. The relying party specifies the attribute in abstract terms, such as "work phone". Then, in the assertion which is created after the End User's authorization, will contain the specific data server endpoints. > > > 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. > > It depends on what you need to specify, but PAPE has an extension point, AX is extensible from the beginning, so we can do a lot with them. > > > *******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 > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
