<br><br><div class="gmail_quote">On Fri, Mar 13, 2009 at 9:49 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">I don’t see why the delegation feature of OpenID would
particularly interfere. One could be doing exactly the same delegation with
SAML.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">B exploiting the “heavy” nameid modules in SAML, one
could do it rather better than openid does it, not that anyone does - to my
knowledge (At Rapattoni, we accomplish what openid delegation achieves by
non SAML means, seeing as our SAML server doesn’t do nameid. It uses “legacy”
associative-mappings that realty has had deployed for 10 years.)</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">Most of the rules you commented on were about the signals and
the security handshake , not the quality of user authentication. I see no real difference
between SAML.authcontextclass and openid.pape.</span></p></div></div></blockquote><div><br>Yes, and I did not say otherwise.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">The NIST criteria doesn’t impose any trust models –
they do not exclude self-asserting parties, for example (the openid UCI model).
</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">If trust issues are not out of scope, they should be. Assurance
criteria should not be advocating or biasing any administrative elements of operational
policy .</span></p></div></div></blockquote><div><br>I was not really talking about trust issues, but about assurance criteria for delegation.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">…Otherwise, this process will do to SAML/openid …just
what it did to PKI.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0in 0in 0in 4pt;">
<div>
<div style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;">
<p><b><span style="font-size: 10pt;">From:</span></b><span style="font-size: 10pt;"> <a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>
[mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>] <b>On Behalf Of </b>Breno de Medeiros<div class="im"><br>
<b>Sent:</b> Friday, March 13, 2009 9:28 AM<br>
<b>To:</b> Paul Madsen<br>
</div><div><div></div><div class="h5"><b>Cc:</b> OpenID List<br>
<b>Subject:</b> Re: [OpenID] TransparencyCamp and OpenID (U)</div></div></span></p>
</div>
</div><div><div></div><div class="h5">
<p> </p>
<p style="margin-bottom: 12pt;"> </p>
<div>
<p>On Fri, Mar 13, 2009 at 3:42 AM, Paul Madsen <<a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a>> wrote:</p>
<div>
<p>Full NIST LOA requirements for 'assertions' (NIST uses the
term in the inclusive sense and not specific to SAML) are laid in Section
10.3.2 of <a href="http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf" target="_blank">http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf</a><br>
<br>
Focusing on Level 2, the combined assertion requirements of LOA 1 & 2 are<br>
<br>
1a) All assertions recognized within this guideline must indicate the assurance
level of the initial authentication of the Claimant to the Verifier using the
former’s long-term token(s). The assurance level indication within the
assertion may be implicit (e.g., through the identity of the Verifier
implicitly indicating the resulting assurance level) or explicit (e.g., through
an explicit field within the assertion.)</p>
</div>
<div>
<p><br>
Implicit indication could be achieved by public documentation. </p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<p><br>
1b) it must be impractical for an Attacker to manufacture an assertion or
assertion reference that can be used to impersonate the Subscriber. If the
direct model is used, the assertion which is used must be signed by the
Verifier or integrity protected using a secret key shared by the Verifier and
Relying Party, and if the indirect model is used, the assertion reference which
is used must have a minimum of 64 bits of entropy.</p>
</div>
</blockquote>
<div>
<p><br>
Shared secret key => implies that the OP should not accept negotiations over
HTTP. Even DH does not bind the shared key to the verifier because there is no
authenticity.<br>
Response_nonce should have at least 64 bits of entropy.<br>
</p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<p><br>
1c) Assertions shall be specific to a single transaction, and, if assertion
references are used, they shall be freshly generated whenever a new assertion
is created by the Verifier. In other words, assertions and assertion references
are generated for one time use.</p>
</div>
</blockquote>
<div>
<p><br>
Response_nonce, if properly implemented, would guarantee this. Both the RP and
the OP (in check_authentication mode) should verify the nonce for uniqueness.<br>
</p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<p><br>
1d) all assertions sent from the Verifier to the Relying Party must either be
signed by the Verifier, or transmitted from an authenticated Verifier via a
protected channel. In either case, a strong mechanism must be in place which
allows the Relying Party to establish a binding between the assertion reference
and its corresponding assertion, based on integrity protected (or signed)
communications with the authenticated Verifier.</p>
</div>
</blockquote>
<div>
<p><br>
Implies that OP check_authentication should be over SSL only.<br>
</p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<p><br>
1e) assertions that are consumed by a Relying Party which is not part of the
same Internet domain as the Verifier must expire within 5 minutes of their creation.
Assertions used within a single Internet domain, including assertions contained
in or referenced by cookies, however, may last as long as 12 hours.</p>
</div>
</blockquote>
<div>
<p><br>
That means that the RP should reject response_nonces older than five minutes.
Implies some level of clock skew adjustment that OpenID does not provide.<br>
</p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<p><br>
2a) assertions must specify whether the name of the Subscriber is a verified
name or a pseudonym.</p>
</div>
</blockquote>
<div>
<p style="margin-bottom: 12pt;"><br>
Assuming it to be a pseudonym unless otherwise specified by extensions would
satisfy this. </p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<p><br>
2b) assertions shall be protected against manufacture/modification, capture,
redirect and reuse.,</p>
</div>
</blockquote>
<div>
<p><br>
Reuse is prevented by the signature inclusion of the return_to URL,
op_endpoint. Signature also prevents against modification. Protecting against
capture could be understood as a mandate for POST, since GET assertions can be
compromised through the browser history prior to their expiration.<br>
</p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<p><br>
2c) assertions, assertion references and any session cookies used by the
Verifier or Relying party for authentication purposes, shall be transmitted to
the Subscriber through a protected channel which is linked to the primary
authentication process in such a way that session hijacking attacks are
resisted</p>
</div>
</blockquote>
<div>
<p><br>
This is not applicable, as OpenID does not rely on common-domain cookies.<br>
</p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<p><br>
2d) To protect assertions against manufacture, modification, and disclosure,
assertions which are sent from the Verifier to the Relying Party, whether
directly or through the Subscriber’s device, shall either be sent via a
mutually authenticated channel between the Verifier and Relying Party, or
equivalently shall be signed by the Verifier and encrypted for the Relying
Party.</p>
</div>
</blockquote>
<div>
<p><br>
Again, implies that check_authentication should be performed over SSL only.<br>
</p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<p><br>
2e) All assertion protocols used at Level 2 and above require the use of
Approved cryptographic techniques. As such, the use of Kerberos keys derived
from user generated passwords is not permitted at Level 2 or above.</p>
</div>
</blockquote>
<div>
<p><br>
SSL would likely meet such standards.<br>
<br>
<br>
In the surface, it would seem that OpenID could achieve such standard with
minor tweaks of the protocol. However, this perception is misleading. The
standards was developed for non-user-centric systems where the IDP has
out-of-band mechanisms to bind identifiers to real users. In a user-centric system
where users can delegate arbitrary identifiers to the OP, one would expect it
to be necessary to develop an additional set of criteria by which delegation
can be assured to a minimum level of integrity protection. Today delegation can
be achieved reasonably easily via phishing attacks that may appear relatively
benign (do not ask user to enter password credentials, for instance).<br>
<br>
</p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<p><br>
<br>
<br>
paul<br>
<br>
Brett McDowell wrote: </p>
<div>
<div>
<div>
<p>To (what I think is) Chris' point about changing/up-leveling
the discussion out of a "OpenID vs. SAML" or "OpenID is
insecure" sidetrack, and to (what I think is) Johannes' point about
capturing the security requirements that we can base a new work stream on... I
humbly suggest we look at the requirements our friends in the US Government
(and others) are requiring now and are confident they will continue to require
regardless of (and independent of) private sector innovation. I'm
specifically referring to their requirement to compliance to the NIST defined
levels of assurance (LOA). </p>
</div>
<div>
<p> </p>
</div>
<div>
<p>If I were to peer into my crystal ball I would probably see
that most of the compelling applications that governments will open to
3rd-party credentialed citizens are likely to be set to LOA 2 or LOA 3.
How about we shift this conversation to focus on how OP's can offer
OpenID-based services to their users that achieve government recognized
compliance to LOA 2 (and soon after, LOA 3)?</p>
</div>
<div>
<p> </p>
</div>
<div>
<p>Some work on this has already been *started* but not
progressed in earnest. Project Concordia has some use cases that look at this
problem space. The Identity Assurance Framework looks at how any
particular credential service can achieve LOA 1 through LOA 4. What we
don't have is any analysis of what an OP could achieve with OpenID 2.0.
Knowing this will provide a clear gap analysis of what we have vs. what
we need. We can base our deliberations on these hard facts. I can only
believe this will be more productive than... actually I don't see any
alternative to this approach if we are serious about making progress.</p>
</div>
<div>
<p> </p>
</div>
<div>
<p>Next Steps?</p>
</div>
<div>
<p> </p>
</div>
<div>
<p>Since I work closely with the primary US Government agency
in charge of procurement (which is quite important to the issue of what/which
IT infrastructure Federal agencies deploy), and because they already require
our certification for all federation technology prior to being considered by
agencies for procurement (this is all SAML and/or PKI today -- just to
clear up any confusion about the usage of SAML in eCitizen
applications), and since they are working closely with us to adopt our
credential assessment framework for LOA 1-2 in the very near future (and LOA
3-4 down the road), I would be happy to talk with them about co-hosting a
kick-off event to drill into this issue as it relates to OpenID specifically.
I assume they will be interested. They, like I, would like to see
citizens be able to use whatever private sector credentials they "already
have" to access government applications. If those are OpenID's, then
lets make sure those OpenID's are going to be acceptable to these federal
Relying Parties (who knows, we might learn something that helps us win more RP
adoption in other markets as well).</p>
</div>
<div>
<p> </p>
</div>
<div>
<p>Thoughts?</p>
</div>
<div>
<p> </p>
</div>
<div>
<div>
<p> </p>
<div>
<div>
<div>
<p><span style="font-size: 9pt; color: black;">Brett McDowell | +1.413.652.1248 | <a href="http://info.brettmcdowell.com" target="_blank">http://info.brettmcdowell.com</a></span></p>
</div>
</div>
</div>
<p> </p>
<div>
<div>
<p>On Mar 12, 2009, at 9:05 PM, Peter Williams wrote:</p>
</div>
<p><br>
<br>
</p>
<div>
<div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
</div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">I’ve been playing with dynamic SAML metadata modes
recently. Instead of reading a signed XRDS file, peers dynamically sign
SAML metadata files. A SAML metadata file is only XML, and has extensions:
one of which could include an XRD or 2 (and thus get signed XRD off the
ground). You can look at the SAML endpoints as funky XRD services, all
expressed in their own markup.</span><span style="color: black;"></span></p>
</div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
</div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">The best thing that ever happened to SAML2 was openid – as
[most of] the SAML crowd have largely got off their ultra high horse and been
forced to match openid in simplicity and effectiveness (or be made irrelevant).</span><span style="color: black;"></span></p>
</div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
</div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
</div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
</div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
</div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span><span style="color: black;"></span></p>
</div>
<div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0in 0in 0in 4pt;">
<div>
<div style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;">
<div>
<p><b><span style="font-size: 10pt; color: black;">From:</span></b><span style="font-size: 10pt; color: black;"> <a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>
[<a href="mailto:general-bounces@openid.net" target="_blank">mailto:general-bounces@openid.net</a>] <b>On
Behalf Of </b>Chris Messina<br>
<b>Sent:</b> Thursday, March 12, 2009 3:59 PM<br>
<b>To:</b> Johannes Ernst<br>
<b>Cc:</b> OpenID List<br>
<b>Subject:</b> Re: [OpenID] TransparencyCamp and OpenID (U)</span><span style="color: black;"></span></p>
</div>
</div>
</div>
<div>
<p><span style="color: black;"> </span></p>
</div>
<div>
<div>
<p><span style="color: black;">On Thu, Mar 12, 2009 at 4:37 PM,
Johannes Ernst <jernst+<a href="http://openid.net" target="_blank">openid.net</a>@<a href="http://netmesh.us" target="_blank">netmesh.us</a>> wrote:</span></p>
</div>
<div>
<div>
<p><span style="color: black;"><br>
On Mar 12, 2009, at 9:46, Ben Laurie wrote:</span></p>
</div>
<div>
<p><span style="color: black;">I agree that all of SAML is way
too large a pill to swallow but<br>
there's no reason subsets that are usable cannot be defined, and,<br>
indeed, have been.</span></p>
</div>
<div>
<p><span style="color: black;"> </span></p>
</div>
</div>
<div>
<p><span style="color: black;">I would love it if somebody was
actually starting a working group (in Apache they would call it
"incubate") that would propose all the gory details of a "more
secure" form of OpenID that still fits into the decentralized,
discovery-based OpenID architecture. Only then can we tell what may or may not
be the better approach.</span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;"> </span></p>
</div>
</div>
<div>
<p><span style="color: black;">+1.</span></p>
</div>
<div>
<div>
<p><span style="color: black;"> </span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;">I'm not the person to do it,
simply because I don't have the background, but I'm really no longer interested
in the discussion that "OpenID isn't good enough for high-value
transactions". Tell that to the Japanese who are already pushing payments
over/with OpenID.</span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;"> </span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;">If it's got security issues, as
Johannes said, we should collect a list of them as issues and go about finding
suitable solutions, best practices or explanations for WONTFIX-type
resolutions.</span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;"> </span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;">The reality is, people will use
OpenID in all kinds of cases that we can't be able to anticipate; SAML (again,
from what I hear — being mostly SAML ignorant) is that SAML requires
sysadmins to maintain and more and more organizations want to move away from
that kind of model. </span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;"> </span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;">HTTP succeeds because (among many,
many other reasons) you can jack up your service to things like S3 once you
realize that you're not really saving any money as a small to mid-sized
organization running a server farm. The same thing applies to user
authentication and security over time, where it'd be nice to have a fairly
straight-forward, interoperable protocol for doing authentication. From what
I've heard, I don't question the sophistication or technological pedigree of
SAML; it's just that when I hear people say that OpenID isn't secure enough,
it's like saying we should all switch to RDF because it's OMG-so-much-better.</span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;"> </span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;">I don't doubt that either are, if
your primary concerns in life are centered around the problems that these
technologies solve; but for folks for whom security isn't necessarily their
only responsibility, and they no longer have an IT department or staff to
manage a SAML solution and look to OpenID as a potential answer — saying
that OpenID isn't secure enough doesn't seem to be an answer to the question "well,
then what do I use?"</span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;"> </span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;">How do we get from where we are
today to a point where OpenID really does solve a large number of security
problems — if only because it hopefully means fewer passwords in use
overall — and fewer unique accounts to maintain? Look, let's take another
look at this: it isn't just "is OpenID by itself secure?" It's:
"given how OpenID changes the makeup of and behavior in the overall
ecosystem, are we now more secure than we were before?" In general, I
think the answer is yes, though of course good security necessitates vigilance
and constant improvement.</span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;"> </span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;">To Johannes point: are we
capturing these needed improvements anywhere, and if not, can we begin to?</span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;"> </span></p>
</div>
</div>
<div>
<div>
<p><span style="color: black;">Chris<br>
<br clear="all">
<br>
-- <br>
Chris Messina<br>
Citizen-Participant &<br>
Open Web Advocate-at-Large<br>
<br>
<a href="http://factoryjoe.com" target="_blank">factoryjoe.com</a> # <a href="http://diso-project.org" target="_blank">diso-project.org</a><br>
<a href="http://citizenagency.com" target="_blank">citizenagency.com</a> # <a href="http://vidoop.com" target="_blank">vidoop.com</a><br>
This email is: [ ] bloggable [X] ask first [ ]
private</span></p>
</div>
</div>
</div>
</div>
<p><span style="font-size: 9pt; color: black;">_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a></span></p>
</div>
</div>
<p> </p>
</div>
</div>
</div>
</div>
<pre style="text-align: center;"><hr align="center" size="4" width="90%">
</pre>
<div><pre> </pre><pre>_______________________________________________</pre><pre>general mailing list</pre><pre><a href="mailto:general@openid.net" target="_blank">general@openid.net</a></pre><pre><a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a></pre>
<pre> </pre></div>
<pre style="text-align: center;"><hr align="center" size="4" width="90%">
</pre><pre> </pre><pre>No virus found in this incoming message.</pre><pre>Checked by AVG. </pre><pre>Version: 7.5.557 / Virus Database: 270.11.10/1996 - Release Date: 11/03/2009 8:42 PM</pre><pre> </pre>
<div>
<p> </p>
<div>
<p>-- <br>
<span style="font-size: 10pt;">Paul Madsen<br>
e:paulmadsen @ <a href="http://ntt-at.com" target="_blank">ntt-at.com</a><br>
p:613-482-0432<br>
m:613-282-8647<br>
web:<a href="http://connectid.blogspot.com" target="_blank">connectid.blogspot.com</a><br>
</span><a href="http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1" target="_blank"><span style="text-decoration: none;"><img src="cid:image001.gif@01C9A3C0.2D1096C0" alt="ConnectID" border="0" height="82" width="400"></span></a></p>
</div>
</div>
</div>
<p style="margin-bottom: 12pt;"><br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a></p>
</blockquote>
</div>
<p><br>
<br clear="all">
<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)</p>
</div></div></div>
</div>
</div>
</blockquote></div><br><br clear="all"><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>