Hi Patricia, <div><br></div><div>I am from Japan, and I think I am working on a set of similar requirement. </div><div>Much of my daytime work is with the Japanese government as well. </div><div>No wonder Artifact Binding (AB) that I, together with John Bradley (who has been working with the </div>
<div>U.S. ICAM SC) etc. , am working on seem to fulfill lots of the requirements. </div><div><br></div><div>My comments inline: <br><br><div class="gmail_quote">On Wed, Jun 9, 2010 at 4:45 AM, Wiebe, Patricia CITZ:EX <span dir="ltr"><<a href="mailto:Patricia.Wiebe@gov.bc.ca">Patricia.Wiebe@gov.bc.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">At IIW in May, we think we heard a call for people to submit their requirements towards</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">the development of the next version of OpenID specifications. This email is intended</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">to contribute some requirements from the B</font></span><span lang="en-ca"><font face="Calibri">ritish</font></span><span lang="en-ca"> <font face="Calibri">C</font></span><span lang="en-ca"><font face="Calibri">olumbia</font></span><span lang="en-ca"><font face="Calibri"> Government. </font></span></p>
<p dir="LTR"><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">At this time, BC Gov goes not specifically promote the use of OpenID like the US ICAM</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">profiles, however we are watching what you’re up to, and will consider the v.Next</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">protocol for our future. We are pleased to see the new and continued efforts to tackle</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">the tough issues surrounding this.</font></span><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">In BC, we have an emphasis on and advocate federated identity approaches that will</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">enable governments to put higher valued services online for our citizens and businesses. </font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">At this time, OpenID 2.0 does not meet those objectives. Check out this recent blog post</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">about BC Gov’s lack of support for OpenID and how our CIO Dave Nikolejsin defended our</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">position, and even Dick Hardt chimed in:</font></span></p>
<p dir="LTR"><span lang="en-ca"></span><a href="http://eaves.ca/2010/05/31/canadian-governments-how-to-waste-millions-online-30m-and-counting/" target="_blank"><span lang="en-ca"><u><font color="#0000FF" face="Calibri">http://eaves.ca/2010/05/31/canadian-governments-how-to-waste-millions-online-30m-and-counting/</font></u></span><span lang="en-ca"></span></a><span lang="en-ca"><font face="Calibri"> </font></span></p>
<p dir="LTR"><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">To summarize what I propose below, we need federated approaches meet the</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">requirements of </font></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">- </font></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-ca"> <font face="Calibri">using various identity assurance frameworks (Canada and BC have our own</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">“LOA” frameworks)</font></span></p>
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">- </font></span><span lang="en-ca"> <font face="Calibri">supporting identity attribute exchange</font></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">- </font> <font face="Calibri">using multiple parties for authentication and attributes</font></span></p>
<p dir="LTR"><span lang="en-ca"></span><span lang="en-ca"><font face="Calibri">Furthermore, we think that these requirements are similar to what other governments need. </font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">We may have different frameworks and policies, different rules about identity attributes,</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">and different technical architectures. It would be great to have a federated approach that</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">is flexible enough for us to use in such an environment.</font></span><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">BC Gov also worked on requirements for an overall identity metasystem, through a forum of</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">identity industry experts back in 2007. This work is published at</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"></span><a href="http://www.cio.gov.bc.ca/cio/idim/idm_forum.page" target="_blank"><span lang="en-ca"><u><font color="#0000FF" face="Calibri">http://www.cio.gov.bc.ca/cio/idim/idm_forum.page</font></u></span><span lang="en-ca"></span></a><span lang="en-ca"><font face="Calibri">. Even though this work presumes an</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">identity agent, many of the requirements are still relevant to a non-identity agent model. </font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"><b><font face="Calibri">Requirements from BC Government towards an improved OpenID protocol</font></b></span><span lang="en-ca"><b></b></span></p>
<p dir="LTR"><span lang="en-ca"><b></b></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">The following are general requirements to satisfy both a federated approach to authentication</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">and the corresponding exchange of identity attributes. It is presumed that such a protocol, in</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">its simplest case, would involve a request from the relying party to an identity provider, and a</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">response from an identity provider to a relying party that satisfies the request. </font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">The following emphasizes the requirements of a protocol that supports a scalable, flexible and</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">extensible model. It describes the use of parameters within the protocol to achieve security</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">and privacy related policies. It does not describe requirements for user experience or</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">passive/active support –</font></span><span lang="en-ca"> <font face="Calibri">but</font></span><span lang="en-ca"> <font face="Calibri">yes, we need all of that too.</font></span><span lang="en-ca"><font face="Calibri"> And yes, I realize that some of these</font></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">requirements</font></span><span lang="en-ca"><font face="Calibri"> sound like</font></span><span lang="en-ca"> <font face="Calibri">“</font></span><span lang="en-ca"><font face="Calibri">other</font></span><span lang="en-ca"><font face="Calibri">”</font></span><span lang="en-ca"><font face="Calibri"> federation protocols.</font></span><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">Requirements for the request:</font></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">a) </font></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-ca"> <font face="Calibri">The request must allow the relying party to indicate one or more specific policies related</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">to requirements for authentication methods, levels of identity assurance or other similar</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">security or privacy policies. </font></span></p></ul></ul></div></blockquote><div>PAPE extension seems to allow it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><ul dir="LTR"><ul dir="LTR"><p dir="LTR"><span lang="en-ca"><font face="Calibri"> </font></span></p>
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">b) </font></span><span lang="en-ca"> <font face="Calibri">The request must allow the relying party to indicate one or more specific attributes, the</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">corresponding attribute values or a range of values that are expected to be sent, and the</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">level of verification and potentially other metadata about the attributes. These may be</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">identity related attributes or other contextual attributes, such as a request for the disclosure</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">of the authentication method that was used by the identity provider.</font></span></p></ul></ul></div></blockquote><div><br></div><div>AX extension seems to allow it, though you would have to define the "verification level" as a </div>
<div>parameter as well. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">c) </font></span><span lang="en-ca"> <font face="Calibri">The request must allow the relying party to indicate the type of token (or allowable types</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">of tokens) that it can accept within the response.</font></span></p></ul></ul></div></blockquote><div>I suppose you are not using "token" in the sense of SP800-63. If it is, then PAPE can do it. </div>
<div>If the "token" means "types of assertion", AB defines a variable called "atype" in the request </div><div>to allow the RP define it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">d) </font></span><span lang="en-ca"> <font face="Calibri">The request must allow the relying party to indicate the security policy to be applied to the</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">response or token in the response, such as whether and how to use encryption or digital</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">signing within the token, or whether and how to send the response over TLS.</font></span></p></ul></ul></div></blockquote><div>RP may specify the digital signature and encryption method through AB request. </div>
<div>AB requires TLS. There is no option for "plain text". I think that is reasonable. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">e) </font></span><span lang="en-ca"> <font face="Calibri">The request must allow the relying party to identify itself in a secure manner, to allow the</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">identity provider to optionally verify the relying party before proceeding with the request.</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">Similarly, the request must allow the relying party to not identify itself, to allow the identity</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">provider to act without regard to or disclosure of the relying party.</font></span></p></ul></ul></div></blockquote><div>AB has two ways for the RP to identify itself. The primary and recommended means it to do it through </div>
<div>the digital signature (RSA) that is applied to the direct assertion request. It allows us to achieve the </div><div>non-repudiation of the request as well. </div><div><br></div><div>The other way, which is slightly simpler, is for the RP to send shared secret to the IdP. </div>
<div>It does not provide the non-repudiation. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">f) </font></span><span lang="en-ca"> <font face="Calibri">The request must be able to fully contain all parameters of the request such that the identity</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">provider can act on the request without needing to have an out-of-band configuration about</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">the relying party.</font></span></p></ul></ul></div></blockquote><div>OpenID in general, including AB, fulfills it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"></span><span lang="en-ca"><font face="Calibri">Requirements for the response:</font></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">g) </font></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-ca"> <font face="Calibri">The response should conform to the request from the relying party, and contain a restatement</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">of the policies that were applied from the request.</font></span></p></ul></ul></div></blockquote><div>PAPE allows us to do it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">h) </font></span><span lang="en-ca"> <font face="Calibri">The response must contain one or more tokens that contain the specific attributes requested.</font></span></p>
</div></blockquote><div>AX fulfills it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">i) </font> <font face="Calibri">The response must allow the identity provider to identify itself in a secure manner, to allow the</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">relying party to optionally verify the identity provider before accepting the response.</font></span></p></ul></ul></div></blockquote><div>Since AB requires the direct assertion request to be over TLS, the RP can verify the IdP's </div>
<div>identity at that level. </div><div><br></div><div>In addition, in AB, the IdP digitally signs the response (RSA-SHA256) when required by the </div><div>relying party. It provides another layer of identification, and non-repudiation as well. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"></span><span lang="en-ca"><font face="Calibri">General requirements:</font></span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">j) </font></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-ca"> <font face="Calibri">For any of the above request parameters, the parameter should be allowed to be left unspecified,</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">in which case the identity provider can determine what to do; be specified using</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">industry-standardized values, or be specified using custom values so that a relying party and</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">identity provider can create their own extensions.</font></span></p></ul></ul></div></blockquote><div>I am not fully grasping this requirement. Could you kindly explain it a little more? </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">k) </font></span><span lang="en-ca"> <font face="Calibri">The request parameters should be specified with a richer language, instead of specifying the</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">specific parameters as a strict set of values, to allow for extensibility and more complexity.</font></span></p></ul></ul></div></blockquote><div>I am not sure if I grasped the requirement completely, but if you mean that relying party should </div>
<div>be able to specify the set of required attributes etc. flexibly, AX seems to handle it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ul dir="LTR">
<ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">l) </font></span><span lang="en-ca"> <font face="Calibri">The protocol should facilitate multiple identity providers to be used to satisfy a relying party’s</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">requirements. Two common examples are i) when one identity provider handles the</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">authentication event and another identity provider supplies identity attributes; and</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">ii) when one identity provider handles the authentication event and some identity attributes,</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">and another identity provider supplies additional identity attributes. In these cases, context</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">and attributes need to be passed from one identity provider to another.</font></span></p></ul></ul></div></blockquote><div>This is exactly what I am dealing with AB and Contract Exchange (CX). </div>
<div>For a brief description of them, you can look at: </div><div><br></div><div><a href="http://bitbucket.org/openid/ab/wiki/Home">http://bitbucket.org/openid/ab/wiki/Home</a></div><div><br></div><div>AND</div><div><br></div>
<div><span class="Apple-style-span" style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 12px; white-space: pre; "><a href="http://public.iwork.com/document/?a=p275492430&d=ABC_of_OpenID-AB.key">http://public.iwork.com/document/?a=p275492430&d=ABC_of_OpenID-AB.key</a></span></div>
<div><br></div><div><span class="Apple-style-span" style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 12px; white-space: pre; "></span>The second one was presented at the OpenID Summit EU by John Bradley yesterday. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">m) </font></span><span lang="en-ca"> <font face="Calibri">The protocol should include an extension for how an identity provider should publish its</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">capabilities (authentication methods and other security policies that it can perform, and which</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">attributes it can supply), so that a relying party can determine whether the identity provider is</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">capable of meeting its requirements.</font></span></p></ul></ul></div></blockquote><div>It is the job of XRDS for public data. </div><div><br></div><div>From the privacy perspective, it is undesirable to publish where the person's attribute can be </div>
<div>obtained before authorizing the relying party, because it may reveal some of my privacy. </div><div>For example, if it is published that my work related data can be obtained from <a href="https://data.nri.co.jp/">https://data.nri.co.jp/</a>, </div>
<div>then the viewer may infer that I am employed by NRI. </div><div><br></div><div>Thus, in AB (and CX), the in the first step, only the IdP is identified. </div><div>The relying party specifies the attribute in abstract terms, such as "work phone". </div>
<div>Then, in the assertion which is created after the End User's authorization, </div><div>will contain the specific data server endpoints. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">n) </font></span><span lang="en-ca"> <font face="Calibri">The protocol should be written such that different industries or communities can write profiles</font></span><span lang="en-ca"> </span></p>
<ul dir="LTR"><ul dir="LTR">
<p dir="LTR"><span lang="en-ca"><font face="Calibri">of it to satisfy their need to write standards that meet their specific requirements for policies</font></span><span lang="en-ca"> </span></p>
<p dir="LTR"><span lang="en-ca"><font face="Calibri">and attribute exchanges.</font></span></p></ul></ul></div></blockquote><div>It depends on what you need to specify, but PAPE has an extension point, </div><div>AX is extensible from the beginning, so we can do a lot with them. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><ul dir="LTR"><ul dir="LTR">
</ul></ul>
<p dir="LTR"><span lang="en-ca"></span><span lang="en-ca"></span></p>
<p dir="LTR"><span lang="en-ca"><b><i></i></b></span><span lang="en-ca"><b><i></i></b></span><b><i><span lang="en-us"></span></i></b><b><i><span lang="en-us"><font color="#365F91" size="2" face="Calibri">Patricia Wiebe</font></span></i></b><span lang="en-ca"></span><span lang="en-us"></span><span lang="en-us"><font color="#1F497D" face="Calibri"><br>
</font></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-us"></span><span lang="en-us"><font color="#365F91" size="2" face="Calibri">Senior Identity Architect, Architecture & Standards Branch</font></span><span lang="en-ca"></span><span lang="en-us"></span><span lang="en-us"><font color="#1F497D" face="Calibri"><br>
</font></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-us"></span><span lang="en-us"><font color="#365F91" size="2" face="Calibri">Office of the Chief Information Officer, Province of BC</font></span><span lang="en-ca"></span><span lang="en-us"></span><span lang="en-us"><font color="#1F497D" face="Calibri"><br>
</font></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-us"></span><span lang="en-us"><font color="#365F91" size="2" face="Calibri">Phone: 250.387.6818 Mobile: 250.514.7685</font></span><span lang="en-ca"></span><span lang="en-us"></span><span lang="en-us"><font color="#1F497D" face="Calibri"><br>
</font></span><span lang="en-ca"></span><span lang="en-ca"></span><span lang="en-us"></span><span lang="en-us"><font color="#365F91" size="2" face="Calibri">Email: <a href="mailto:Patricia.Wiebe@gov.bc.ca" target="_blank">Patricia.Wiebe@gov.bc.ca</a></font></span><span lang="en-ca"></span><span lang="en-us"></span></p>
<p dir="LTR"><span lang="en-ca"></span></p>
</div>
<br>_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>