To be exact, it is one direct POST, one indirect GET, then one direct GET all from RP->OP. It is the same as OAuth so I believe it can be done at a large OP such as Google/Yahoo! etc.
=nat http://www.sakimura.org/en/ http://twitter.com/_nat On Thu, 20 Aug 2009 21:14:39 -0500, John Bradley <john.brad...@wingaa.com> wrote: > 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<sakim...@gmail.com> >> wrote: >>> John, >>> >>> On Thu, Aug 20, 2009 at 10:11 AM, John Bradley <john.brad...@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.brad...@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.brad...@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.ha...@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-boun...@lists.openid.net >>>>> [openid-specs-boun...@lists.openid.net] on behalf of John Bradley >>>>> [john.brad...@wingaa.com] >>>>> Sent: Tuesday, August 18, 2009 3:27 PM >>>>> To: Allen Tom >>>>> Cc: openid-specs@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<sakim...@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 <jbrad...@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 >>>>>>>>> <jbrad...@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 >>>>>>>>> sp...@lists.openid.net >>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nat Sakimura (=nat) >>>>>>>> http://www.sakimura.org/en/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> specs mailing list >>>>>>>> sp...@lists.openid.net >>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> specs mailing list >>>>>> sp...@lists.openid.net >>>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>> >>>>> _______________________________________________ >>>>> specs mailing list >>>>> sp...@lists.openid.net >>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>> >>>>> _______________________________________________ >>>>> specs mailing list >>>>> sp...@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 >>> sp...@lists.openid.net >>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> >> >> >> >> _______________________________________________ specs mailing list sp...@lists.openid.net http://lists.openid.net/mailman/listinfo/openid-specs
