This is very good work. I must admit that I never took a good look at artifact binding. Because I had this impression that artifact binding is about AX. Now that I have read the spec I can see that there is much more to it than AX. It looks more like a rewrite of the core protocol itself.
Yes I know this is going to raise some eyebrows here. But seriously, all we need to do is add webfinger to this and Viola we have OpenID V.Next. (Yes I agree it is not as simple as that, but I hope you get the gist of what i am suggesting). Also will it be possible to try this out in other languages like python, i mean can we have a trial OP setup somewhere. On Tue, May 18, 2010 at 4:03 PM, Nat Sakimura <[email protected]> wrote: > The same with Artifact Binding 1.0 draft 06. It is a chartered work group > at OpenID Foundation. > (OpenID Connect / v.Next etc. needs to be chartered and approved yet.) > It is very similar to David's straw man. Main difference is that you still > can get the same > identifier as OpenID 2.0. It also is a trivially implementable spec. > > See here: https://openid4.us/ for links etc. > > Cheers, > > =nat > > > > (2010/05/17 22:27), Alex Barth wrote: > >> >> Small aside: I've implemented a similar workflow myself recently and I've >> avoided any changes of user account details on Relying Parties: >> >> http://developmentseed.org/blog/2010/mar/02/simple-sign-openid >> >> All changes to accounts properties (user name, email, etc) are done on the >> provider to avoid asynchronicities. >> >> Alex >> >> On May 17, 2010, at 12:03 AM, Manuel Lemos wrote: >> >> Hello, >>> >>> With this thread of using oAuth 2 for identity I am confused to which >>> protocol should I use for a single sign-on solution that I need to >>> implement. >>> >>> Let me explain my case and see if anybody can clarify what is the best >>> solution for me. >>> >>> I have one site, lets call it site A, that has many user accounts. I >>> want to build another site, lets call it site B, but I do not want users >>> with accounts in site A to create new accounts to access site B. They >>> could just use the same account data from site A and use it in site B. >>> In the future I may have sites C, D, etc.. >>> >>> I thought of creating an OpenID authentication server, lets call it OP, >>> and migrate user account from site A to OP. When users go to site A or B >>> and need to login, they are redirected via OpenID to OP for >>> authentication. >>> >>> If successful, OP passes site A or B the account, personal name, nick >>> name and e-mail when redirecting back to sites A or B, so those sites >>> always have copies of that account information for imediate use. >>> >>> If the user updates one of those details in site A or B, they push the >>> changes to OP and OP propagates the changes to the other site A or B >>> that also has the same user account. >>> >>> From the specifications that I read, OpenID and its extensions can be >>>> >>> used the way I need. >>> >>> This will all be used only within my network sites. I do not intend to >>> allow users to autheticate with external OpenID providers, nor I want >>> other sites to use my OpenID provider to authenticate in other sites. >>> >>> Since this is meant for use restricted to my sites, I could invent a >>> proprietary protocol, but I thought it was better to not reinvent the >>> wheel. >>> >>> I will develop all the necessary components to implement the OpenID >>> provider and consumers with the needed extensions. Actually the consumer >>> component is mostly done. >>> >>> I was moving to the OpenID provider component when I noticed this thread >>> of using oAuth 2 for identity. So now I wonder if I am in the right >>> path? Shall I keep doing it with OpenID or shall I do it with oAuth 2? >>> Can anybody please shed some light so I can make the best decision? >>> >>> -- >>> >>> Regards, >>> Manuel Lemos >>> >>> Find and post PHP jobs >>> http://www.phpclasses.org/jobs/ >>> >>> PHP Classes - Free ready to use OOP components written in PHP >>> http://www.phpclasses.org/ >>> _______________________________________________ >>> specs mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >> >> Alex Barth >> http://www.developmentseed.org/blog >> tel (202) 250-3633 >> >> >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> > > > -- > Nat Sakimura > > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場 > 合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメー > ルを削除してくださいますようお願い申し上げます。 > PLEASE READ：This e-mail is confidential and intended for the named re > cipient only. If you are not an intended recipient, please notify the > sender and delete this e-mail. > > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > -- http://hi.im/santosh
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
