Artifact Binding Re: specs Digest, Vol 36, Issue 1
John Bradley
john.bradley at wingaa.com
Fri Aug 21 02:14:39 UTC 2009
Breno,
It could be RESTful but Nat's current proposal involves the OP
synchronizing two information from two GET requests from different
clients in near real time.
For a small OP with a single server that is probably not a significant
problem.
As openID is extensible I am not certain that trying to come up with a
more compact encoding will suffice for Nat.
John B.
On 20-Aug-09, at 1:14 AM, Breno de Medeiros wrote:
> 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<sakimura at gmail.com>
> wrote:
>> John,
>>
>> On Thu, Aug 20, 2009 at 10:11 AM, John Bradley <john.bradley at wingaa.com
>> >
>> wrote:
>>>
>>> Nat,
>>>
>>> You don't have the new Sec 9.4 hi-lighted like the other changes
>>> so I
>>> missed it.
>>
>> Sorry, I fixed it.
>>
>>>
>>> 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)
>>
>> Direct request should take precedence.
>>
>>>
>>> The User authenticates (must happen after the artifact is looked
>>> up or you
>>> need to include PAPE in the indirect request)
>>
>> MUST happen after the artifact look up as the claimed id is in it.
>>
>>>
>>> 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)
>>
>> 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.
>>
>>>
>>> The RP then makes another direct request openid.mode=assertion_req
>>> openid.artifact={artifact}
>>>
>>> The OP then returns the assertion with the extension payload.
>>
>> Yes. It returns the auth and extension payload including claimed
>> identifier
>> etc.
>>>
>>> Am I getting close to what you are thinking?
>>
>> Quite.
>>
>>>
>>> I don't think we should underestimate the synchronization issues
>>> that a OP
>>> will have across a cluster with this.
>>
>> 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.
>>
>>>
>>> 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.
>>
>> 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?
>>
>>>
>>> The two requests coming from different IP will likely wind up on
>>> different
>>> servers.
>>
>> Yes, but in principle, it should not be a problem.
>>
>>>
>>> This on it's own makes data snooping worse not better.
>>
>> I do not get it. Could you explain more?
>>
>>>
>>> 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.
>>
>> 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.
>>
>>>
>>> Without mutual TLS the artifact in the indirect response needs to be
>>> encrypted.
>>
>> 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.
>>>
>>>
>>> I am traditional and still prefer to encrypt the returned token
>>> with the
>>> cert you get from RP discovery to verify the return_to.
>>
>> 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.
>>>
>>>
>>> Your proposal is simple in some ways but I don't know that it
>>> meets all of
>>> the potential use cases.
>>
>> 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.
>>
>>>
>>> If we are going to dig into this I don't know that doing it
>>> outside of WG
>>> IPR coverage.
>>
>> 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.
>>
>>>
>>> John B.
>>>
>>> On 19-Aug-09, at 8:10 PM, Nat Sakimura wrote:
>>>
>>>> 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 <john.bradley at wingaa.com
>>>> >
>>>> 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 <john.bradley at wingaa.com
>>>> >
>>>> 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.
>>>>
>>>> http://wiki.openid.net/OpenIDwithArtifactBinding
>>>>
>>>> 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 <Dick.Hardt at microsoft.com
>>>> >
>>>> 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: openid-specs-bounces at lists.openid.net
>>>> [openid-specs-bounces at lists.openid.net] on behalf of John Bradley
>>>> [john.bradley at wingaa.com]
>>>> Sent: Tuesday, August 18, 2009 3:27 PM
>>>> To: Allen Tom
>>>> Cc: openid-specs at lists.openid.net
>>>> 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:
>>>>
>>>>> 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:
>>>>>>
>>>>>> 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<sakimura at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 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 <jbradley at mac.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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
>>>>>>>> <jbradley at mac.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Some may ask if we add artifact binding, signatures and
>>>>>>>>> encryption are we
>>>>>>>>> not reinventing SAML Web SSO, or something of equal
>>>>>>>>> complexity?
>>>>>>>>>
>>>>>>>> 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: http://factoryjoe.com
>>>>>>>> Follow me on Twitter: http://twitter.com/chrismessina
>>>>>>>>
>>>>>>>> Citizen Agency: http://citizenagency.com
>>>>>>>> Diso Project: http://diso-project.org
>>>>>>>>
>>>>>>>> OpenID Foundation: http://openid.net
>>>>>>>>
>>>>>>>>
>>>>>>>> This email is: [ ] bloggable [X] ask first [ ] private
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> specs mailing list
>>>>>>>> specs at lists.openid.net
>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Nat Sakimura (=nat)
>>>>>>> http://www.sakimura.org/en/
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> specs mailing list
>>>>>>> specs at lists.openid.net
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> specs mailing list
>>>>> specs at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> http://www.sakimura.org/en/
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> http://www.sakimura.org/en/
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> http://www.sakimura.org/en/
>>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
More information about the specs
mailing list