Just to add another merit for artifact, it is very mobile client friendly. <div>It is pretty simple to write a spec for it, and to implement it. </div><div>RSA-SHA sign, we do not have to wait until 3.0. </div><div>If I remember correctly, it was one of the thing to be done in 2.1 timeframe. </div>
<div><br></div><div>=nat</div><div><br><div class="gmail_quote">On Fri, Aug 14, 2009 at 12:55 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">if saml2 satisfies the rule, at "loa=2"and "loa=3", then we don't have to do any more than SAML2 does.<br>
<br>
Why not let a WG profile/amend messages, for use in 12m time, and choose suitable security mechanisms that address the fact that assertion communication is indirect (and request communication is typically indirect).<br>
<br>
Now, we faced what openid faces with indirect communication structures when we (Visa/Mastercard/IBM/VeriSign etc) designed SET; IBM's OAEP saved the day.<br>
<br>
lets reopen the WG for openid auth, for minor releases: 2.1 and 2.2. Fundamentally, lets add public key techniques to the communication plane , in the form of the OAEP. I dont know who Will is, but i'll guess he will implement OAEP in about 30m. Its just a one-time pad, and the generation/use of reversible trapdoor hash-based KDFs that generate the encryption/decryption subkey schedule of a DES-era feistel network).<br>
<br>
Define v2.1 as<br>
1. the simple addition of OAEP as a new "signing" method, and<br>
2. the sensitive information values in a signed assertion can now blank in the cleartext form of the assertion transferred classically, when OAEP is the signing method.<br>
<br>
The point is that the public association + nonces is the source keying material - that OAEP then uses to generate the one time pad that encrypts/signs the request or response under the reversible public key properties of the OAEP scheme.<br>
<br>
define v2.2 as<br>
1. the addition of an artifact binding mode. That is, a private association used by OPs when responding need not sign the assertion any longer, but can sign (using OAEP) a blank assertion template. (The use-once private association handle is the artifact id, itself).<br>
2. Over direct channel and existing flow, enable RP to resolve the private association (= artifactID in SAML speak). Amend verification response so its message can be optionally signed (using OAEP) using a public association, thus delivering the ciphertext of the assertion to the intended recipient as well as the status of the private association resolution (isvalid=true).<br>
<br>
in a v3.0, once you have signed XRD, and add RSA entity public keys (with signing keyusage only) to the (provider-signed) endpoint XRDs, we can address non-repudiation for higher levels of assuraces. One can sign the OAEP ciphertext, using RSA, where the (rsaciphertext,oaepciphertext) is put into the base64 of an openid signature type - for either requests or responses.<br>
<div class="im"><br>
________________________________________<br>
From: <a href="mailto:openid-general-bounces@lists.openid.net">openid-general-bounces@lists.openid.net</a> [<a href="mailto:openid-general-bounces@lists.openid.net">openid-general-bounces@lists.openid.net</a>] On Behalf Of John Bradley [<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>]<br>
</div>Sent: Wednesday, August 12, 2009 10:40 PM<br>
To: Nat Sakimura<br>
<div class="im">Cc: <a href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a><br>
</div><div><div></div><div class="h5">Subject: Re: [OpenID] OpenID + Government<br>
<br>
Nat,<br>
<br>
Look at sec 8.1.2<br>
Eavesdropping resistance: An authentication protocol is resistant to<br>
eavesdropping attacks if an eavesdropper who records all the messages<br>
passing<br>
between a claimant and a verifier or relying party finds that it is<br>
impractical to<br>
learn the private key, secret key or password or to otherwise obtain<br>
information<br>
that would allow the eavesdropper to impersonate the claimant.<br>
Eavesdropping<br>
resistant protocols make it impractical3 for an attacker to carry out<br>
an off-line<br>
attack where he/she records an authentication protocol run then<br>
analyses it on<br>
his/her own system for an extended period, for example by systematically<br>
attempting to try every password in a large dictionary, or by brute<br>
force<br>
exhaustion.<br>
<br>
Also Table 3 on page 39 Required Protections<br>
<br>
Using AX update_url doesn't protect the authentication token.<br>
It would send a unsolicited positive assertion to the RP return_to URL<br>
with a separate token.<br>
<br>
Also 8.2.2.2.Assertions requires that the trusted entity(OP)<br>
authenticates to the RP using a secure protocol. As the OP is<br>
connecting to the RP in the AX case mutual TLS would be required.<br>
<br>
In AX the store message is a indirect message sorry. It is not<br>
relevant to the LoA 2 case in any event as LoA 2 requires protection<br>
against eavesdroppers on the reply.<br>
<br>
Honestly it is better to take LoA 1 now and work on LoA 2 with proper<br>
planning and spec cycle.<br>
<br>
A lot of thought went into the decision not to hold up openID LoA 1 by<br>
trying to include LoA 2 in the same profile.<br>
<br>
We have only covered some of the issues. Password entropy, identity<br>
proofing, liability, and other issues all come into play at LoA 2.<br>
<br>
Getting LoA 1 approved was no cake walk itself.<br>
<br>
I have probably said too much as it is.<br>
<br>
I look forward to the GSA releasing the profile then people will have<br>
something more concrete to criticize. I will happily take the heat<br>
for that.<br>
<br>
John B.<br>
<br>
On 12-Aug-09, at 8:48 PM, Nat Sakimura wrote:<br>
<br>
> Yes. Go for Artifact Binding!<br>
> That happens to be the main road block for even writing CX.<br>
> If we had that, we could completely reuse the OpenID protocols<br>
> already spec'ed out.<br>
> Unfortunately it is not the case.<br>
><br>
> Current thinking is that CX sends the AX store message to OP<br>
> Endpoint in direct communication, which sounds like a bit of<br>
> stretch. Is that OK from AX stand point???<br>
> Hope so. See <a href="http://www.sakimura.org/en/modules/wordpress/index.php?p=89" target="_blank">http://www.sakimura.org/en/modules/wordpress/index.php?p=89</a><br>
> for details in Section 4, Protocol.<br>
><br>
> On the assertion disclosure, I do not read that requirement on NIST<br>
> SP800-63. It only requires "digitally signed by trusted entity" or<br>
> direct communication. (Here, "digitally signed" means signed by<br>
> public key cryptography. OpenID "sign" does not qualify).<br>
><br>
> Which document are you referring to?<br>
><br>
> To cope with "Digital Signature" issue, we can adopt it in OpenID<br>
> 2.1. Alternatively, we can profile AX so that it carries rsa-sha256<br>
> signature.<br>
><br>
> =nat<br>
><br>
> On Thu, Aug 13, 2009 at 5:42 AM, Breno de Medeiros<br>
> <<a href="mailto:breno@google.com">breno@google.com</a>> wrote:<br>
> Complexity could be minimally increased by defining an artifact<br>
> profile.<br>
><br>
> Encryption using artifact profile requires no specification, comes for<br>
> free by having OP SSL endpoints.<br>
><br>
> Artifact profile would reduce the length of URLs, currently a problem<br>
> (not all implementations seem to handle POST very well, and POST can<br>
> be annoying on mobile devices or when changing from SSL to non-SSL<br>
> context). I think it would be more beneficial on that basis than even<br>
> from a security standpoint.<br>
><br>
> Otherwise, I agree with John's assessment.<br>
><br>
> On Wed, Aug 12, 2009 at 1:32 PM, John<br>
> Bradley<<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>> wrote:<br>
> > Kids,<br>
> > The GSA is producing a profile of standards.<br>
> > OpenID 2.0, PAPE and AX are the only standards.<br>
> > Surprisingly SREG 1.1 is not a standard (I guess we just forgot in<br>
> our<br>
> > enthusiasm for AX)<br>
> > The last thing the GSA wants (as I understand it) is to create new<br>
> specs and<br>
> > impose them on the community. This includes picking winners and<br>
> losers in<br>
> > proposed extensions.<br>
> > The GSA has not said that openID can never be LoA 2+ , only that<br>
> given the<br>
> > existing specs available to profile it doesn't meet the criteria<br>
> of SP800-63<br>
> > for LoA 2.<br>
> > The protocol MUST prevent assertion disclosure at LoA 2.<br>
> > That is the main roadblock.<br>
> > Other protocols encrypt the assertion to the RP or use a direct SSL<br>
> > connection (artifact binding)<br>
> > It is a tradeoff that openID community needs to consider carefully,<br>
> > security can be increased to meet LoA 2 but it will be at the<br>
> cost of<br>
> > increased complexity.<br>
> > It may not be a good bargain. That however is a decision for the<br>
> community<br>
> > to make and not the GSA or any other government.<br>
> > I don't believe that CX addresses this issue, it is intended to<br>
> solve a<br>
> > different trust problem.<br>
> > Nat and I have discussed this.<br>
> > If there is a extension to openID or changes to the core spec that<br>
> allow<br>
> > openID to be profiled at LoA 2+ then the GSA or whoever can<br>
> revisit the<br>
> > profile.<br>
> > These things are not cast in stone.<br>
> > Some of the things in the TFAP are a challenge the Shibboleth<br>
> community as<br>
> > well.<br>
> > If a bank wants to send your unencrypted data through a browser as a<br>
> > redirect, good for them.<br>
> > The GSA and OMB have to live within SP800-63, and given that I<br>
> think the<br>
> > decision to profile openID for LoA 1 while the community sort out<br>
> where it<br>
> > wants to go is reasonable.<br>
> > My opinions are my own as always, and not representative of any<br>
> government<br>
> > or organization.<br>
> > Take a deep breath, relax it is all good.<br>
> > John B.<br>
> ><br>
> > Message: 5<br>
> > Date: Wed, 12 Aug 2009 12:25:45 -0700<br>
> > From: Peter Williams <<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>><br>
> > Subject: Re: [OpenID] OpenID + Government<br>
> > To: Paul Madsen <<a href="mailto:paulmadsen@rogers.com">paulmadsen@rogers.com</a>><br>
> > Cc: "<a href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a>"<br>
> > <<a href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a>><br>
> > Message-ID: <<a href="mailto:73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com">73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com</a>><br>
> > Content-Type: text/plain; charset="us-ascii"<br>
> ><br>
> > Ok!<br>
> ><br>
> > So you did what myspace did: took the defined extension points and<br>
> > added value . They discarded the dh handshake, and use a vendor<br>
> > specific association protocol (apparently). Better strength and<br>
> > assurance hopefully... falling back to default (low) assurance ...<br>
> > when no better option can be found.<br>
> ><br>
> > In your case, I'll guess in the endpoint xrd that you advertise -<br>
> per<br>
> > the model -additional extension handler names, so adding value via<br>
> the<br>
> > extension framework. Presumably this offers something suiting<br>
> banking<br>
> > frauds to only those endpoints wanting to rely on xri resolution ...<br>
> > for capability negotiation and address selection (which is the more<br>
> > openid way of doing things).<br>
> ><br>
> > This is all just like ssl, now, where folks up negotiate higher<br>
> > strength mechanisms and higher level operational assurances.<br>
> ><br>
> > But look at the difference In my tone and characterization, when<br>
> > discussing the assurance space.<br>
> ><br>
> > Let's tell the ssl story using a divisive characterization of<br>
> > assurances, now:<br>
> ><br>
> > Oh my god, netscapes 40bit rc4 ciphersuite with crappy pertabators<br>
> in<br>
> > the kdf (broken by a French student) and verisign class 1 client<br>
> certs<br>
> > means ALL of ssl3 is low assurance. Look! GSA confirms it. It's a<br>
> > fact! Folks must now switch to IPsec, for >loa1 assurance level when<br>
> > tunelling!<br>
> ><br>
> > No. Thats not how it was handled. Nsa/Dod comes along, puts in a<br>
> missi<br>
> > ciphersuite, adjusts the handshake flow so missi-style key agreement<br>
> > can share the record layer with rsa handshakes, and dod office<br>
> systems<br>
> > get all the additional strength of missi ciphers and missi<br>
> assurances<br>
> > when talking amongst themselves (now featuring monthly changing user<br>
> > keying material, key comprise handling, flash authority removal,<br>
> > remote cac applet provisioning on gp smartcards...). They can still<br>
> > interwork with public sites using rsa, at low assurance, however.<br>
> ><br>
> > (I'm showing my out of dateness In federal systems. By now, missi<br>
> will<br>
> > have been renamed 6 times...)<br>
> ><br>
> > What we want is Strong, professional security engineering, based<br>
> on cc<br>
> > claims, STD protection profiles, evaluated cryptomodules, even<br>
> formal<br>
> > methods proving the info flow properties of the strong type<br>
> system,...<br>
> > And in grassroots centric openid, We want that all to be developed<br>
> in<br>
> > and shown by common or garden programmers, not just defense<br>
> > contractors working for GSA-affiliated .gov sites<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Aug 12, 2009, at 8:37 AM, "Paul Madsen" <<a href="mailto:paulmadsen@rogers.com">paulmadsen@rogers.com</a>><br>
> > wrote:<br>
> ><br>
> > As you acknowledge ('custom extension albeit'), the application you<br>
> ><br>
> > are<br>
> ><br>
> > referring to supplemented OpenID's own security in order to meet the<br>
> ><br>
> > higher assurance requirements.<br>
> ><br>
> > With the standardization of that 'custom extension' continuing to<br>
> ><br>
> > progress in the OpenID community, perhaps the GSA will in the future<br>
> ><br>
> > reevaluate whether the combination can support higher assurance?<br>
> ><br>
> > The GSA have said (or will say soon I guess) only that OpenID 2.0,<br>
> as<br>
> ><br>
> > profiled, tops out at LOA1 (for US Gov RPs). The profile doeesnt<br>
> ><br>
> > mention<br>
> ><br>
> > (I think at least, I havent read it) CX or any other extensions that<br>
> ><br>
> > might supplement assurance.<br>
> ><br>
> > paul<br>
> ><br>
> > p.s. I believe I am as suspicious of the realty industry as you<br>
> are of<br>
> ><br>
> > Liberty<br>
> ><br>
> > Peter Williams wrote:<br>
> ><br>
> > So there i am in 2006 trying to let our 100k realtors use their rsa<br>
> ><br>
> > tokencodes at lots of other websites in the realty universe.<br>
> ><br>
> > Sounds simple, no?<br>
> ><br>
> > And I walk into this religion style war of words, of spin<br>
> meistering,<br>
> ><br>
> > claim and counterclaim ...and a omnipresent culture of the putdown.<br>
> ><br>
> > Generally: an intense over sensitivity, in the saml camp. And it's<br>
> ><br>
> > not<br>
> ><br>
> > because realty is a hot new market for websso sales!<br>
> ><br>
> > As a lapsed security engineer, i love seeing the passion (and i also<br>
> ><br>
> > love the saml product we selected, which we use everyday at a cost<br>
> of<br>
> ><br>
> > deployment now of about $2000 partner link (taking about 3 days, in<br>
> ><br>
> > most cases)). But the "edginess" I see displayed across not one but<br>
> ><br>
> > several companies is a real issue for going further with saml. I<br>
> feel<br>
> ><br>
> > like I'm stepping across a precipice.<br>
> ><br>
> > And the edginess gets noticibly stronger the moment i talk about<br>
> ><br>
> > (also) using openid in our customers trust networks.<br>
> ><br>
> > Now you are a good person to challenge on the bretts topic of "GSA<br>
> ><br>
> > has<br>
> ><br>
> > declared openid as inherently unable to address more than loa1<br>
> ><br>
> > assurance requirements". A firm you associate with has been using<br>
> ><br>
> > openid (with a custom extension albeit) for banking transactions-<br>
> ><br>
> > which are not trivial transactions for which low assurance is<br>
> ><br>
> > appropriate.how can I reconcile those 2 statements?<br>
> ><br>
> > Now I feel I'm being spun to even more. Brett made, in literary<br>
> ><br>
> > analysis, a reaching for that "defining" gsa classification. And in<br>
> ><br>
> > that act of reaching underminded his case for being impartial. A<br>
> good<br>
> ><br>
> > politician doesn't reach for the very classification device that<br>
> ><br>
> > devides folks. He or she enables (almost magically) a acceptable<br>
> ><br>
> > tradeoff.<br>
> ><br>
> > Is kantara going to formally disarm the samlista brigade and move<br>
> ><br>
> > forward, or have we just got a new name for the same old warhorse?<br>
> ><br>
> ><br>
> ><br>
> > Grudgingly, they acceptedn<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Aug 12, 2009, at 4:10 AM, "Paul Madsen" <<a href="mailto:paulmadsen@rogers.com">paulmadsen@rogers.com</a>><br>
> ><br>
> > wrote:<br>
> ><br>
> > Peter, a good theory. But you forget to mention that NORAD<br>
> ><br>
> > intentionally<br>
> ><br>
> > scrambled the fighters late to allow the planes to get to the<br>
> ><br>
> > towers.<br>
> ><br>
> > Peter Williams wrote:<br>
> ><br>
> > My value- such as it is- is as an outsider.<br>
> ><br>
> > I measured 4 sources:<br>
> ><br>
> > Sun Micro rsa conference presentation on their openid pilot;<br>
> ><br>
> > rationales for never being an rp<br>
> ><br>
> > Ping identity factors gating speed of adoption of openid2 -<br>
> ><br>
> > privileged acess<br>
> ><br>
> > Scott cantors view on openid2 generally, and saml as used in xrd;<br>
> ><br>
> > raw opinion, shared freely<br>
> ><br>
> > How the uk jisc pilot of openid framed the basis for it's total<br>
> ><br>
> > adoption failure in uk academia. Was it geared to fail?<br>
> ><br>
> > Given these 4 inputs, I simply conjectured a link (liberty). I<br>
> ><br>
> > tested my conjecture by being a bit outlandish. CoMpared to the<br>
> ><br>
> > norm (fox news and msnbc), I was MILD in the imputations. Lots of<br>
> ><br>
> > Ifs, buts, shoulds, mays....that mature heads would recognize as<br>
> ><br>
> > method.<br>
> ><br>
> > Don't get upset. It's just an experiment.<br>
> ><br>
> > Little, powerless, clueless, skilless, informationless peter throws<br>
> ><br>
> > tiny word stone at mighty million dollar liberty standards lobbying<br>
> ><br>
> > machine ...and gets "over the top" reaction.<br>
> ><br>
> > Why? Why such sensitivity?<br>
> ><br>
> ><br>
> ><br>
> > On Aug 11, 2009, at 5:29 PM, "John Bradley"<br>
> ><br>
> > <<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a><mailto:<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>>> wrote:<br>
> ><br>
> > Peter, Brett<br>
> ><br>
> > As a member of Liberty, Kantara, ICF, and OIDF. I can say that I<br>
> ><br>
> > have never seen any indication of Liberty plotting against openID<br>
> ><br>
> > or info-card. (I do go to most of the secret meetings)<br>
> ><br>
> > The issue with physical access is more one of not trying to boil<br>
> ><br>
> > the ocean.<br>
> ><br>
> > There is real desire by real government RPs to use open<br>
> ><br>
> > technologies and work with commercial identity providers. There<br>
> ><br>
> > are RPs I am working with who want this yesterday.<br>
> ><br>
> > This first step is hard enough. Many people have been working hard<br>
> ><br>
> > for many months.<br>
> ><br>
> > One of the ways we have been able to make progress is by limiting<br>
> ><br>
> > the scope.<br>
> ><br>
> > We could have done physical access, LoA 4, p-cards and other<br>
> ><br>
> > things.<br>
> ><br>
> > The initial program by the GSA is a start not an end to the<br>
> ><br>
> > process.<br>
> ><br>
> > There will be changes to the initial profiles and additional<br>
> ><br>
> > profiles as time and requirements permit.<br>
> ><br>
> > This first step is a scary amount of work, give us time please.<br>
> ><br>
> > John B.<br>
> ><br>
> > On 11-Aug-09, at 5:04 PM, <mailto:<a href="mailto:openid-general-request@lists.openid.net">openid-general-request@lists.openid.net</a><br>
> ><br>
> > <a href="mailto:openid-general-request@lists.openid.net">openid-general-request@lists.openid.net</a><mailto:<a href="mailto:openid-general-request@lists.openid.net">openid-general-request@lists.openid.net</a><br>
> ><br>
> > wrote:<br>
> ><br>
> > Date: Tue, 11 Aug 2009 13:43:29 -0700<br>
> ><br>
> > From: Peter Williams<br>
> ><br>
> > <<mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>><a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a><mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a><br>
> ><br>
> > Subject: Re: [OpenID] OpenID + Government<br>
> ><br>
> > To: Brett McDowell<br>
> ><br>
> > <<mailto:<a href="mailto:email@brettmcdowell.com">email@brettmcdowell.com</a>><a href="mailto:email@brettmcdowell.com">email@brettmcdowell.com</a><mailto:<a href="mailto:email@brettmcdowell.com">email@brettmcdowell.com</a><br>
> ><br>
> > Cc: OpenID List<br>
> > <<mailto:<a href="mailto:general@openid.net">general@openid.net</a>><a href="mailto:general@openid.net">general@openid.net</a><mailto:<a href="mailto:general@openid.net">general@openid.net</a><br>
> ><br>
> > Message-ID: <<mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><br>
> ><br>
> > <a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><br>
> ><br>
> > Content-Type: text/plain; charset="us-ascii"<br>
> ><br>
> > If the infocard stack is technically reputable, can you explain why<br>
> ><br>
> > an<br>
> ><br>
> > accredited provider would be excluded from using it (and openid)<br>
> ><br>
> > from<br>
> ><br>
> > making assertions of physical presence?<br>
> ><br>
> > _______________________________________________<br>
> ><br>
> > general mailing list<br>
> ><br>
> > <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><mailto:<a href="mailto:general@lists.openid.net">general@lists.openid.net</a>><br>
> ><br>
> > <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
> ><br>
> > _______________________________________________<br>
> ><br>
> > general mailing list<br>
> ><br>
> > <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
> ><br>
> > <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > ------------------------------<br>
> ><br>
> > _______________________________________________<br>
> > general mailing list<br>
> > <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
> > <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
> ><br>
> ><br>
> > End of general Digest, Vol 36, Issue 13<br>
> > ***************************************<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > general mailing list<br>
> > <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
> > <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
> ><br>
> ><br>
><br>
><br>
><br>
> --<br>
> --Breno<br>
><br>
> +1 (650) 214-1007 desk<br>
> +1 (408) 212-0135 (Grand Central)<br>
> MTV-41-3 : 383-A<br>
> PST (GMT-8) / PDT(GMT-7)<br>
> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
><br>
><br>
><br>
> --<br>
> Nat Sakimura (=nat)<br>
> <a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
</div></div></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>
</div>