Artifact Binding Re: specs Digest, Vol 36, Issue 1

=nat sakimura at gmail.com
Fri Aug 21 02:53:13 UTC 2009


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.bradley at 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<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
>>>
>>>
>>
>>
>>
>>


More information about the specs mailing list