<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
In the interest of improving security, would it make sense to require
the RP to sign the request when exchanging the Artifact for the
response? If the request was signed, then even if the artifact was
easedropped, possession of the artifact by itself does not allow the
attacker to get the data.<br>
<br>
Given that many RPs don't use HTTPS, it's very likely that Artifacts
will be passed around in the clear. Although requiring the RP to sign
the request when exchanging the artifact for the assertion would
increase the complexity, it might be worth it.<br>
<br>
Allen<br>
<br>
<br>
<br>
<br>
Nat Sakimura wrote:
<blockquote cite="mid:4A8D1485.1090004@nri.co.jp" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Hi Breno, <br>
<br>
Since the Artifact needs to be unique, it just cannot be simply
ax-e_bd_zip etc., but needs some random attached to it. <br>
But then, do we want a semantics like that in the RESTful URL? <br>
<br>
I think a URL like: <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://example.com/op?openid.artifact=15fdso2djal234">http://example.com/op?openid.artifact=15fdso2djal234</a>
<br>
<br>
can represent some set of attributes with an identity == a resource. <br>
It is an abstract URL for this set of resources. <br>
You could construct an alias like: <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://example.com/breno/e_bd_zip">http://example.com/breno/e_bd_zip</a>
<br>
which is a more human readable version of it. <br>
<br>
POST to the URL creates a resource that represents the set of resources
in question. <br>
GET to the URL returns the resource. <br>
<br>
It is still RESTful, IMHO. <br>
<br>
=nat<br>
<br>
Breno de Medeiros wrote:
<blockquote
cite="mid:29fb00360908192314j6fe212cfgf41e163b17e2e1ce@mail.gmail.com"
type="cite">
<pre wrap="">Hi John,
I think this could be implemented in a RESTful way.
For instance, an OP could create a really compressed scheme to
represent the payload initially sent by the RP. For instance, if an OP
supports email address, birthday, and zip code, and the RP has
requested all of them, you could make the artifact be: ax-e_bd_zip
In other words, there is no need why an artifact cannot be constant
for a particular set of attributes. If the user does not approve all
of them, the OP could return a different artifact in the response
(there should be the assumption that the artifacts are distinct, and
the OP endpoint to redeem the artifact should be part of the
response).
On Wed, Aug 19, 2009 at 7:02 PM, Nat Sakimura<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:sakimura@gmail.com"><sakimura@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">John,
On Thu, Aug 20, 2009 at 10:11 AM, John Bradley <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:john.bradley@wingaa.com"><john.bradley@wingaa.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Nat,
You don't have the new Sec 9.4 hi-lighted like the other changes so I
missed it.
</pre>
</blockquote>
<pre wrap="">Sorry, I fixed it.
</pre>
<blockquote type="cite">
<pre wrap="">Lets see if I follow this now.
The RP sends a direct request openid.mode=art_res to the OP (9.4) with
AX, PAPE parameters and the OP provides a (10.3) Artifact response.
The RP then makes a indirect request with openid.artifact set to the value
obtained from the artifact response.
The OP then looks up the request based on the artifact. (conflicting
parameters are resolved in some way)
</pre>
</blockquote>
<pre wrap="">Direct request should take precedence.
</pre>
<blockquote type="cite">
<pre wrap="">The User authenticates (must happen after the artifact is looked up or you
need to include PAPE in the indirect request)
</pre>
</blockquote>
<pre wrap="">MUST happen after the artifact look up as the claimed id is in it.
</pre>
<blockquote type="cite">
<pre wrap="">The user consents to releasing attributes.
The OP returns a positive assertion with openid.artifact in the response
(you need to include that in 10.1)
</pre>
</blockquote>
<pre wrap="">Sequence-wise, the OP does not return a positive assertion here but it
returns an Artifact Response (10.3).
Positive assertion is returned later.
I am not sure if openid.artifact is needed in the positive assertion since
it is returned as the response to the assertion request as openid.artifact
as one of the request parameter.
</pre>
<blockquote type="cite">
<pre wrap="">The RP then makes another direct request openid.mode=assertion_req
openid.artifact={artifact}
The OP then returns the assertion with the extension payload.
</pre>
</blockquote>
<pre wrap="">Yes. It returns the auth and extension payload including claimed identifier
etc.
</pre>
<blockquote type="cite">
<pre wrap="">Am I getting close to what you are thinking?
</pre>
</blockquote>
<pre wrap="">Quite.
</pre>
<blockquote type="cite">
<pre wrap="">I don't think we should underestimate the synchronization issues that a OP
will have across a cluster with this.
</pre>
</blockquote>
<pre wrap="">I agree. We need to be clever on how artifact should be hashed and stored.
e.g., store (artifact,payload) pair on distributed storage in such a way
that you can locate the location from artifact (e.g., if the Artifact is an
URL, it is trivial).
FYI, in CX, I have made the artifact created by the RP so that RP to OP
request is always with the Artifact, so that a load balancer can land the
request to the same server. Perhaps that's a better way but has a side
effect that the indirect request gets bigger.
</pre>
<blockquote type="cite">
<pre wrap="">We would be bending the principals of REST with this. I would like to
get the opinion of some of the larger OPs on this.
</pre>
</blockquote>
<pre wrap="">I am not so sure about it (bending REST).
Think of it like this:
The authentication request over direct communication is stored on the server
side (the OP) as a resource and the OP returns a Resource URI, which is
called "Artifact".
The RP makes a GET request to a resource uri constructed from the OP End
Point URI and the Artifact.
Is this bending REST?
</pre>
<blockquote type="cite">
<pre wrap="">The two requests coming from different IP will likely wind up on different
servers.
</pre>
</blockquote>
<pre wrap="">Yes, but in principle, it should not be a problem.
</pre>
<blockquote type="cite">
<pre wrap="">This on it's own makes data snooping worse not better.
</pre>
</blockquote>
<pre wrap="">I do not get it. Could you explain more?
</pre>
<blockquote type="cite">
<pre wrap="">We need mutual TLS for the direct connection where the OP verifies the
return_to URI against the cert of the incoming connection.
Unless the claimed_id is only passed in the direct session it probably
would not meet the no snooping requirement. I need to consult on that.
</pre>
</blockquote>
<pre wrap="">The claimed_id is only passed in the direct session. In the Artifact
binding, it is only the Artifact and signature that are sent through
indirect communication.
</pre>
<blockquote type="cite">
<pre wrap="">Without mutual TLS the artifact in the indirect response needs to be
encrypted.
</pre>
</blockquote>
<pre wrap="">Does it have to be mutual TLS? Of course, it is better that way, but I do
not want to raise the bar too much.
</pre>
<blockquote type="cite">
<pre wrap="">I am traditional and still prefer to encrypt the returned token with the
cert you get from RP discovery to verify the return_to.
</pre>
</blockquote>
<pre wrap="">Are you talking about the Artifact or the Data?
For Data, yes, I do, too.
I was also going to encrypt the Artifact, but SAML was not doing that so I
left it unencrypted.
</pre>
<blockquote type="cite">
<pre wrap="">Your proposal is simple in some ways but I don't know that it meets all of
the potential use cases.
</pre>
</blockquote>
<pre wrap="">Without the list of use cases, it is difficult to estimate :-)
My primary use case is mobile. I think it satisfies it. For more security
oriented things, you can use something like CX ;-) Of course, that requires
more complexity, namely, the public key discovery, payload digital
signature, payload encryption, etc.
</pre>
<blockquote type="cite">
<pre wrap="">If we are going to dig into this I don't know that doing it outside of WG
IPR coverage.
</pre>
</blockquote>
<pre wrap="">You are right. Since CX covers artifact in its scope, it might be good
discussing it under CX WG IPR. In parallel, we can spin up Authn 2.1 WG and
move the discussion there.
</pre>
<blockquote type="cite">
<pre wrap="">John B.
On 19-Aug-09, at 8:10 PM, Nat Sakimura wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi John,
Ah! I think it is so called "Framing Problem".
When I modified the 2.0 spec to create this 2.1 draft 0.001, I have
removed all the restrictions that authentication messages have to be
indirect. So, now, it can be direct as well. When using direct, to link it
with user action, the artifact is used.
See inline:
On Thu, Aug 20, 2009 at 1:52 AM, John Bradley <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:john.bradley@wingaa.com"><john.bradley@wingaa.com></a>
wrote:
Hi Nat,
inline
On 19-Aug-09, at 12:32 PM, Nat Sakimura wrote:
Hi John,
Inline:
On Wed, Aug 19, 2009 at 10:30 PM, John Bradley <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:john.bradley@wingaa.com"><john.bradley@wingaa.com></a>
wrote:
Nat,
On a first read through.
Your proposal only solves half the problem, in that it only reduces the
size of the indirect response. With extensions it is still possible to
likely that requests will go over 2K.
Why is that so?
All the extensions can use this direct communication path.
What was sent over indirect communication is sent over direct
communication.
If the full request must be made indirectly that doesn't reduce the
request size.
As stated above, the full request can be made directly. In that case,
only artifact and a few others moves indirectly. Thus, it will reduce the
request size drastically, putting upper bound for the indirect request size.
Are you thinking that the authentication is done via a indirect request
but CX, AX etc all happen via direct communications?
No. Main body of Authentication request, and thus extension requests, are
sent via direct request and only the artifact and a few others are sent via
indirect communications.
Unless you send the attributes that are going to be requested in the
indirect request how would the user provide consent to release them to the
RP?
The request is sent from the RP to the OP over the direct communication.
Then, the user is taken from the RP to the OP over the indirect
communication carrying the Artifact. The OP, upon receipt of the Artifact,
can reconstruct the main request from it. Then, the user consent etc.
happens as usual. Then, instead of the OP sending the positive assertion
back to the RP, it sends the Artifact and the user back to the RP over the
indirect communication signifying that it has completed the processing at
the OP. Using the Artifact, the RP fetches the (+ve or -ve) assertion from
the OP through the direct communication. Verification etc. goes on then as
usual there after.
Also openID relies on validating the users presence via a cookie. That
would not be available to the OP in a direct session.
Hopefully now you see why it works. It changes almost nothing. It just
pushes the main payload to the direct communication and that's it. Others do
not change.
I would prefer not to have to revisit this again once the request size
becomes an issue.
The OP needs to advertise that it supports the binding in it's XRD/S.
In this draft, I made the support of direct communication mandatory and
the version of the OpenID Authn protocol was raised to 2.1. This is
advertising that it supports the binding in its XRD/S.
I don't know that making it mandatory is necessarily a good idea. There
may be other things in 2.1 that may be useful aside from a artifact binding.
I prefer the idea that a OP could optionally support the binding and it
would be discoverable.
I don't feel super strong about it, but others may.
Right. I just wanted to be a minimalist and also wanted the spec to be
fairly symmetric. If the artifact is to be an optional binding, then it
would have to define a new type URI. However, from the sake of being
symmetric, then, we should define type URI for the indirect binding as well
and list it on XRD/S.
As you point out this doesn't do anything for security. The artifact
will need to be encrypted or mutual TLS used for the direct connection.
The encryption of the Artifact is an open question, as SAML Artifact
binding does not encrypt the Artifact either siting that in this limited
size that the encryption is unpractical.
For the mutual authentication, I could incorporate relevant sections of
CX here as well. That will make the already thin CX spec even thinner.
You are going to make me read CX aren't you:)
Yes. If you leave the contract schema alone, then it is extremely
concise.
In testing something close to 1% of RP and OP have TLS implemented
correctly now. Mutual TLS may impossible to implement in some
environments.
It is easy to say just use TLS for that, and make it someone else's
problem. Mutual TLS may be the best option but encrypting the fragment and
using normal TLS should also be considered.
Having the OP POST to the RP directly should also be considered, that
would work for LoA 2 but probably not LoA 3 without mutual TLS.
That's unsolicited direct response, and it is not precluded in this
draft.
No unsolicited assertions are still indirect.
As I have explained above, in this draft, unsolicited assertions can be
direct. It may have no association with the user session as well. If it
does, then the user has to be at the OP to start with, and the User has to
be taken to the RP with the Artifact.
I was thinking of a flow where the OP makes two replies one indirect and
the other direct.
That is exactly what is in my draft, though the indirect one is optional.
The main reason not to do this is that it would not work with RP load
balancing. Likely they go to different servers.
We have that problem now with nonces.
I think this is an implementation problem.
The implementation should have some kind of shared storage behind the
server farm and store the direct response to with the Artifact as the key.
When the user landed on one of the server, the server can pull the data from
the shared storage, and that's it.
Note that the unsolicited direct response without user being taken back
to the RP works. It works for AX update etc.
Also, I have constructed the protocol to be "easier to implement" for
RPs.
If they do not support unsolicited direct response, that is still OK.
It is only this feature that uses the OP to the RP communication unlike
SAML's case.
It is always the RP making request to the OP.
Artifact binding is simple in principle but the devil is in the details.
Is there anything else?
We can create an issue tracker and solve them one by one.
I actually do not foresee too many of them.
Also, we should not try to solve all the use cases.
Being able to satisfy 90% of them should be good enough.
John B.
There are a number of tradeoffs with different methods.
A good attempt to show how this method would work.
John B.
On 19-Aug-09, at 5:51 AM, Nat Sakimura wrote:
Been sick and not following the various discussion around artifact since
last Saturday, so I might be out of sync but here is my shot for Artifact
Binding which I hoped to provide on Friday 14th.
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://wiki.openid.net/OpenIDwithArtifactBinding">http://wiki.openid.net/OpenIDwithArtifactBinding</a>
It is about 40 lines of modification/addition. The portion that I
changed/added are in RED so it should be easy for you to find out.
Its sequence is a bit different than SAML Artifact binding as I tried to
minimize the impact to the current deployments.
It has done nothing about encryption. The direct communication should be
over the verified TLS channel. Security implication of the Artifact exposure
on the indirect communication should be further discussed, but my
preliminary assessment is that it should be ok.
=nat
On Wed, Aug 19, 2009 at 8:42 AM, Dick Hardt <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:Dick.Hardt@microsoft.com"><Dick.Hardt@microsoft.com></a>
wrote:
my $0.02
I expect the data moving between the RP and OP to become even larger over
time, therefore a standard, alternative mechanism for moving the data
directly between the RP and OP, particularly when bandwidth to the client is
constrained, seems desirable.
I would generally prefer a proven, widely deployed encryption mechanism
such as TLS rather then adding functionality to OpenID
-- Dick
________________________________________
From: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:openid-specs-bounces@lists.openid.net">openid-specs-bounces@lists.openid.net</a>
[<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:openid-specs-bounces@lists.openid.net">openid-specs-bounces@lists.openid.net</a>] on behalf of John Bradley
[<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>]
Sent: Tuesday, August 18, 2009 3:27 PM
To: Allen Tom
Cc: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:openid-specs@lists.openid.net">openid-specs@lists.openid.net</a>
Subject: Re: Artifact Binding Re: specs Digest, Vol 36, Issue 1
One of the things you need for LoA 2 is to prevent eavesdropping.
The choices are encrypt the response to the RP or use direct
communication with TLS (probably mutual) if the RP is going to make a
direct request to the OP.
Using an artifact binding has advantages and disadvantages. Using it
to get around the 2K URI limit in IE would put any RP not supporting
it at a disadvantage.
It might be acceptable if the RP could indicate its support for
artifact binding in the request and allow the OP to use artifact
instead of post.
With mobile devices becoming more common I can see people preferring
an artifact binding over the existing ones.
It is a real change to the protocol and will add complexity supporting
another binding.
One short term fix that Andrew Arnott implemented in DotNetOpenAuth is
a smart detection of OP's support for AX vs SREG and preferring SREG
if it is supported. Most people are only using AX for the SREG
attributes anyway.
I agree that the AX attribute URI need to get sorted out anyway. We
could look at making them shorter when we mint new standard ones.
John B.
On 18-Aug-09, at 6:02 PM, Allen Tom wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi All,
Sorry for the delayed response, I'm still catching up on mail after
being on vacation last week.
Breno - How would artifact binding help OpenID attain Loa2? I'm
unclear as to how that would make a difference.
The Yahoo OP was recently updated to return responses that are
larger than 2KB using POST, and this has caused many users to see
the ugly browser warning because most RPs don't support HTTPS.
Displaying the ugly browser warning is really unacceptable, so we'll
probably update the Yahoo OP to only use POST only for HTTPS
return_to URLs.
The excessively large responses are mostly due to AX being
excessively verbose. It would be really nice if we could revise AX
to be a lot more compact. Perhaps if we had a standardized AX
schema, we'd be able to shorten the message size.
Allen
Breno de Medeiros wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Since Google was mentioned here as wanting artifact, let me make the
record clear to say that I spoke about artifact binding on my
personal
capacity.
My very own personal view is that an artifact profile would be easy
to
spec out (the check_authentication or stateless mode is already the
artifact flow without the additional benefits of artifact) and would
make OpenID more robust. Currently long URLs require POST which only
gives you so much mileage. POST is ugly if the RP has a non-HTTPS
endpoint, with scary user confirmation dialogs.
Also, I did not wish to express any personal opinion on whether
OpenID
should seek Loa2, just to note that artifact is the easiest route
there.
On Thu, Aug 13, 2009 at 10:45 AM, Nat Sakimura<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:sakimura@gmail.com"><sakimura@gmail.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">John,
You changed the topic of this thread.
This thread was about artifact binding, not about Government LoA.
That's another thread :-)
Yes, Artifact helps LoA, but it is not only that.
It helps the mobile space immensely.
=nat
On Fri, Aug 14, 2009 at 2:00 AM, John Bradley <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:jbradley@mac.com"><jbradley@mac.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Chris
I think we are agreeing. OpenID needs to play to it's strengths.
Chasing shiny things is tempting.
We need to carefully consider the impact of changes.
That is not to say that openID shouldn't evolve.
There are always tradeoffs.
Remember that a GSA LoA 2 or 3 profile is focused on the Gov
accepting the
assertions for specific uses.
Other people are free to make there own determinations for other
use
cases.
I am interested in finding out if IdP really want to be certified
at LoA 2
with all of the extra identity
proofing, liability and other things that go with that.
A LoA 2 certification for a IdP involves a lot more than just
tweaking
some protocol peaces.
Are there OPs that want that?
John B.
On 13-Aug-09, at 9:11 AM, Chris Messina wrote:
On Thu, Aug 13, 2009 at 8:34 AM, John Bradley <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:jbradley@mac.com"><jbradley@mac.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Some may ask if we add artifact binding, signatures and
encryption are we
not reinventing SAML Web SSO, or something of equal complexity?
</pre>
</blockquote>
<pre wrap="">I would like to know more about this, but my instinct is always
to say
"NO" for as long as possible when any new feature will a) introduce
complexity and b) stifle or impair potential adoption.
That we've come as far as we have is a feat; maintaining that
momentum is
critical — and that means making good on the promise of what
OpenID offers
*today* — and only extending it with real world examples where
people are
implementing kludges (en masse) to serve a common need.
Chris
--
Chris Messina
Open Web Advocate
Personal: <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://factoryjoe.com">http://factoryjoe.com</a>
Follow me on Twitter: <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a>
Citizen Agency: <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://citizenagency.com">http://citizenagency.com</a>
Diso Project: <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://diso-project.org">http://diso-project.org</a>
OpenID Foundation: <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://openid.net">http://openid.net</a>
This email is: [ ] bloggable [X] ask first [ ] private
_______________________________________________
specs mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<pre wrap="">--
Nat Sakimura (=nat)
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a>
_______________________________________________
specs mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">_______________________________________________
specs mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
specs mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
_______________________________________________
specs mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
--
Nat Sakimura (=nat)
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a>
--
Nat Sakimura (=nat)
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a>
--
Nat Sakimura (=nat)
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">
--
Nat Sakimura (=nat)
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a>
_______________________________________________
specs mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<pre wrap=""><!---->
--
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
_______________________________________________
specs mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
specs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<br>
</body>
</html>