fidzu : OpenID

At F8 today, Facebook rolled out their Facebook Connect platform. With a small amount of code, other sites can integrate the Facebook identity system into their site. The keynote reminded me of early days of Microsoft as they rallied developers to build on their platform by explaining how the platform can help them and being inclusive. They even seemed humble as they talked about what they have done wrong in the past and then reaching out to developers asking for their feedback. They even have a fund and a competition for best applications.

Facebook Connect is a powerful identity system. Using Facebook Connect, a site gets access to the user's profile data and the users friends. For sites such as Digg and Movable Type that want to make users accountable for their activity, there is an implicit reputation of the user based on the depth of the profile. It is much more difficult for a spammer to build a Facebook identity to spam these participatory sites. Facebook is all about real identity rather then a fake persona. Facebook even has rich privacy controls so that users feel in control of who sees what.

The promise of OpenID was to make login simple and move profile data. A number of us have been looking at using OpenID to make an accountable web. Given the momentum and immediate value of a Facebook identity system and the lack of OpenID RP deployment, one wonders if the identity opportunities of OpenID have passed.

The announcement from MySpace supporting OpenID may enable a more open identity system to evolve, but Facebook has a compelling offering that provides significant value to sites - well, as soon as Facebook Connect is launched anyway.

23 Jul 2008 10:13pm GMT

We've got some great upgrades to our service ready, but we'll need to take the service offline to roll them out. So, myVidoop will be unavailable tomorrow morning (7/24/08) from 7am to 9am CDT. We'll be introducing some new features which we'll tell you about in a later blog post (or just check out the site tomorrow after 9am).

23 Jul 2008 8:26pm GMT

We are very proud that Chris Messina (aka @factoryjoe), a recent addition to the Vidoop team, has recently received the award for 'best community amplifier'. You can read about the history and see past winners at the Google-O'Reilly Open Source Awards - Hall of Fame but the general idea is…

The Google-O'Reilly Open Source Awards have been presented to individuals for dedication, innovation, leadership and outstanding contribution to open source.

Winners are selected by a committe, made up of the following: Allison Randal, (The Perl Foundation & O'Reilly - OSCON Co-Chair), Brady Forest (O'Reilly - Technology Evangelist and Conference Chair), Brian Behlendorf (CollabNet CTO and Founder), Chris DiBona (Google, Open Source Programs Manager), Danese Cooper (Open Source Diva, Intel), David Ascher (CTO, ActiveState, and director, Python Software Foundation), Tim O'Reilly (Founder and CEO of O'Reilly Media), Nat Torkington (O'Reilly - OSCON Co-chair), Zaheda Bhorat (Google, Open Source Programs Manager).

Chris has consistently been at the forefront of the Open Web movement and an outspoken advocate of open source technologies. Since being introduced to him and the open web/identity community a little over a year ago, he has personally been very helpful in navigating the landscape, making introductions and genuinely a fun guy to hang out with. I am sure I join the rest of the Vidoop team and web community at large in congratulating Chris on a job well done and wishing him continued success in whatever ventures he pursues. Whatever it is, the web will be better off because of it

23 Jul 2008 4:37am GMT

Fellow Perl hackers,

I'm happy to announce that the Google App Engine team has given me permission to talk about a 20% project inside Google to to add Perl support to App Engine. To be clear: I'm not a member of the App Engine team and the App Engine team is not promising to add Perl support. They're just saying that I (along with other Perl hackers here at Google) are now allowed to work on this 20% project of ours out in the open where other Perl hackers can help us out, should you be so inclined.

As background, I've been writing Perl code for almost 15 years now and quite fond of the language. (I'm "bradfitz" on CPAN.) Here at Google, though, it's not one of our big languages so I don't get to write as much Perl as I used to. I'd still like to run my personal web apps on App Engine, though, and I'd like to write them in Perl. And I'm definitely not alone, looking at how many people have starred the wishlist bug. Some of you have already started talking about it. We'd like to join the discussion, and start hacking out in the public.

In the process we can build the start of an open source App Engine server clone that's suitable for many purposes: initially just for regression testing & local development (like the "dev_appserver" that comes with the App Engine Python SDK), but perhaps in the future (once Hypertable/Hbase/etc are ready) a full stack to give to ISPs to let them run App Engine apps on their own.

Before I get into my proposed roadmap, let me describe what's publicly known about the App Engine architecture. In a nutshell, it looks like this:

The App runs in a multi-layer hardened environment, one layer of which will need to be a hardened Perl interpreter.

Basically, we need a hardened Perl runtime which can:

• open & read files
• NOT write files
• NOT open sockets
• NOT fork
• NOT do any other system functionality that's not strictly needed for a web app

Basically we need a Perl interpreter that's very tame and isn't allowed to do anything other than read web requests and write out responses. Any privileged operations (like Datastore access, fetching URLs, etc) need to be done via a trusted XS Perl module (the "apiproxy") that takes a service request parameter and returns a service response. The request and response are both encoded as Protocol Buffers, which were recently open sourced by Google.

Perl on App Engine then would involve the following steps (in no particular order):

• Hardened Perl Interpreter: basically, we'll be statically linking in a hardened, customized libperl to a C++ application, disabling all Perl dynamic loading. Only vetted, security-audited XS modules will be allowed. Only safe Perl opcodes will be allowed. (No sockets, no ioctl, no fork, etc, etc.) To get a preview for what this'll feel like restriction-wise, check out the newly written Sys::Protect which Artur and I wrote this evening and will be continuing to develop for people's dev environments (not production).
• Protocol Buffers for Perl: we need support for Protocol Buffers for Perl. I've started on this project internally and will open source the code soon, once I have a few free minutes.
• Server: we need to write an App Engine server for testing, local development, and potentially production deployment. (Replace Bigtable with MySQL, Hypertable, Hbase, Couch DB, etc.)
• Libraries: Perl client libraries for Datastore, URLFetch, etc services. Including docs.

Not included is the Google-internal side of things, gluing the hardened Perl interpreter into the GAE world. That needs to be done by a Googler and not open source.

If you'd like to discuss this and/or help out, join the perl-appengine mailing list. We'll be submitting code to the appengine-perl project on Google Code hosting. For more information about this, see the Perl-on-AppEngine FAQ.

Brad & the other Perl Googlers

23 Jul 2008 3:49am GMT

Ariel Gordon, in charge of everything identity at France Telecom / Orange, tells me that Orange.fr, their portal, is now OpenID-enabled.

This must be one of the largest OpenID Relying Parties so far. Congratulations, Ariel!

23 Jul 2008 3:36am GMT

22 Jul 2008 7:30pm GMT

We're proud to announce that Draft 5 of the Email Address to URL Transformation (EAUT) specification is now available. What does this mean to me you may be asking yourself? It means that coming soon to an OpenID login form near you, you will be able to use your email address as an OpenID.

In basic terms EAUT makes it easy to take an email address and transform it into an URL, making your email work with services like OpenID. The goal with Emailtoid is to demonstrate the technology and provide a fallback solution for a larger, decentralized network based on the EAUT specification.

Using an email addresses as a login is already a familiar process. The problem is that an email address is not very useful as an endpoint for identity information. A URL is much better for storing identity information, though using a URL to login is counter intuitive. This is the usability disconnect that EAUT aims to address.

With EAUT, email providers can host an XRDS document at their root (eg, aol.com). Here's an example XRDS document:

<?xml version="1.0″ encoding="UTF-8″ ?>
<XRDS xmlns="xri://$xrds">
    <XRD xml:id="main" xmlns="xri://$xrd*($v*2.0)" version="2.0″ xmlns:simple="http://xrds-simple.net/core/1.0″ xmlns:openid="http://openid.net/xmlns/1.0″>
        <Type>xri://$xrds*simple</Type>
        <Service priority="10″>

            <Type>http://specs.eaut.org/1.0/template</Type>
            <URI>http://openid.aol.com/%7Busername%7D</URI>
        </Service>
    </XRD>
</XRDS>

If the example email is vidooprocks@aol.com, The above XRDS document, hosted on aol.com, would mean that the resulting URL is http://openid.aol.com/vidooprocks - which is a valid OpenID (or would be if somebody had that email).

Now, what happens when the email provider doesn't have an XRDS document, or has one but doesn't have any EAUT types in there? You use a fallback service - just like Emailtoid!

With EAUT, relying parties can now have the best of both worlds. They can ask for email addresses, which people are used to, but still only have to implement OpenID. Please let us know if you have any questions or feedback on our Emailtoid support page.

22 Jul 2008 5:40pm GMT

Techcrunch: MySpace To Join OpenID, Bringing Total Enabled Accounts to Over A Half Billion.

21 Jul 2008 11:55pm GMT

OSCON 2008 by itself is enough to geek out about, but don't forget about the parties!

• Tuesday, July 22, 7pm: Django Drinkup! come to Jax Bar to meet other Djangonauts from OSCON and the Portland area. We reserved the Jax Bar rooftop patio. It's easy and free to get to Jax from the Convention Center on the MAX. We'll be getting started between 6pm-7pm. For more info contact @mtrichardson

• "Wednesday, July 23: FOSCON! Being held at Cubespace, FOSCON is a Ruby gathering (I know, I know) but they want to have a competition between the big three frameworks - Rails, Django, and CakePHP. One team per framework, teams are two people each, official rules at http://pdxfoscon.org/competition - if you think you've got what it takes to represent Django in this event, drop @mtrichardson a line."

• Thursday, July 24, doors open at 6pm for the SourceForge Community Choice Awards which will be hosted at the Jupiter Hotel. There will be buses running between the party and the convention center starting at 5:30. Oh ya… and you may be able to get a free tattoo

• Thursday, July 24, 8pm-11pm: Beerforge III will be held at Bossanova. Highlights include free shuttles from the SourceForge party, all you can drink open bar (mixed drinks, beer, wine), lots of swag, excellent catering from Fords on 5th (read bacon wrapped dates) including some awesome vegan dishes, and maybe some other surprises… thanks to Jive Software, Mozilla, OpenSourcery, OSL, Songbird, and Vidoop for sponsoring!

If you fall in love with Portland and decide to stay, the good times keep rollin' with a Django sprint on August 22 from 9am to 6pm here at the Vidoop offices.

21 Jul 2008 8:09pm GMT

21 Jul 2008 7:42pm GMT

Let's play "name the opposing relationship". rel="employer" is to rel="employee" as:

• rel="attendee" is to ... ?
• rel="member" is to ... ?
• rel="venue" is to ... ?

rev is not an acceptable solution, and is being removed in HTML5. What's the alternative?

20 Jul 2008 8:17pm GMT

Headed up to Portland this afternoon for OSCON and just put my schedule online if you want to check it out. I won't be there Wednesday as I'll be down at Facebook f8 for the day. Then back up Thursday for a 9:15am keynote on Supporting the Open Web!

Really busy week, with no sleep for me, but should be tons of fun and I look forward to seeing a bunch of awesome people!

20 Jul 2008 7:23pm GMT

第三回 Liberty Alliance 技術セミナーで=natさんの基調講演を公聴してきて、OpenID関連の動向を仕入れたのでメモ。

OPとRP間で属性情報を交換するための拡張として、SREGやAXがあるが、AXも今ひとつ普及するに至っていない。(myopenid.comとVeriSignだけ？)また、プライバシポリシーや利用規約の問題もあり、日本企業では、ユーザ属性をサードパーティに公開出来ない事も多い。

基本的に、AXとSREGの違いは、

• 交換可能な属性をコミュニティベースで提案&決定する
• 属性を識別するために、プリミティブな値でなく、ネームスペースURIを使う
• OPに要求する属性の個数が指定可能
• RPがOPに対して属性の保存をする事が可能。(ただし、使われているプロバイダは知らない。)

が挙げられるが、根本的な問題は、OpenIDのユーザ属性として、クレジットカード番号や電話番号などプライバシー性の高い情報を使う事など、気が狂っていると思われている事だ。AXへの本格的な以降が進まないのは、結局OpenIDで扱うユーザ属性は、ニックネームやメールアドレスのみで、SREGで十分に事が足りているからではないだろうか。

さて、単純なユーザ属性の交換と、OP側でのユーザの許可の仕組みしか提供していないAXに代わる仕様として、Trusted Data Exchangeが=natさん、=masakiさん (NRI)から提出されている。

TXのコンセプトには次のような物が含まれる。

• 契約ベースの属性提供
• XML Encryption/XML Signatureによる暗号化•書名
• 非同期な属性提供 (非否認性を持った契約ベース)
• RPの信憑性を判断するReputation Platform (現状のホワイトリストに代わる)

仕様は既に、提案済みで、仕様が取り込まれる方向で話が進んでいる様子。OpenIDによるログインフォームは、会員登録の敷居を下げる。結果的に、サービスを利用する敷居が下がり、クレジットカートや住所などの個人情報が信頼できないRPに渡る可能性が高くなる。ユーザ属性ポータビリティには、Reputation Platformの構築は、急務であると言える。

年内に取り込まれるだろうか？

もう一つの最新動向は、PAPEの仕様拡張。PAPEと言えば、OpenIDの認証強度を明示するためのOpenID拡張だが、採用するセキュリティモデルを明示的に指定するための仕様を提案しているとの事。現状のPAPEでは、NISTの定めるセキュリティモデルを指定できるだけであるが、日本のFISCの基準を採用する際には、次のように指定できるとの事だ。

openid.pape.auth_level.fisc:2

openid.pape.auth_level.ns.fisc: http://www.fisc.or.jp/ex/authlevel

See also: まちゅダイアリー - SAML と OpenID と CardSpace

19 Jul 2008 3:12am GMT

Shot another episode of TheSocialWeb.tv with John and Joseph yesterday. Focused mainly on Meebo's new Community IM and how it's continuing the trend of making the entire web more social. Check it out and I'll be at both Facebook f8 and OSCON next week.

18 Jul 2008 4:34pm GMT

myVidoop.com will be down for server maintenance from 12am - 2am CDT July 18, 2008. We appologize for not posting this notice sooner.

Update: the maintenance window is actually from 12am - 4am CDT; we apologize for any inconvenience this may cause.

Update: the maintenance has been completed and myvidoop.com is back online.

18 Jul 2008 4:36am GMT

While OpenID 2.0 has certainly been a big step forward, it's clear that much technical work remains to be done to make OpenID as useful and as broadly applicable as possible. (And don't get me started on how much marketing work needs to be done...)

Here's my list of what I'd like to see us in the OpenID community work on from now through 2009. We don't need to do all of it at once of course. I'm blogging this so I can get some feedback ...

Note: I do not know how to solve all of them, but then, that's what we have the brainy OpenID community for ;-)

• Sessions. If I'm authenticated at 1 OP and 5 RPs, all 6 of them are attempting to figure out independently from each other whether or not I'm still at my PC, and when they should expire their session cookies and challenge me again. It would be more user-friendly, and more secure, if they could somehow figure this out together. For example, RP 3 should be able to ask the OP "My user has not done anything in his session in the last 15 minutes, any indication that he's still at this PC?" and the OP should be able to answer "He's been continually using RP 5, with less than 10 seconds between page views ever since, so you can keep your session open." Perhaps single-sign-out also falls into this category.
• OP-initiated SSO. In LID, it's very easy to put a HREF together that, when clicked on, sends the user's browser to a site and authenticates them, zero user input and zero redirects required. In OpenID Authentication 1 and 2, that's much harder to do and might not work in the general case. Let's fix this: SSO-enabled bookmarks are really useful.
• Browser functionality. The Mozilla guys always wanted to hear from us in the OpenID community how to best add native OpenID support into the browser. What about we show them, preferably with working code?
• RP requests for particular credential types. A range of OPs now has more than one credential type they support, sometimes as multiple factors to be used together. It would be nice if not only the OP could tell the RP what credential type was used, but also let the RP ask the OP for a particular credential type. This is one of the use cases in the PAPE draft, so perhaps all we need to do is get it finished.
• Distributed QA. We need much better processes for letting our users tell us that the combination of OP X and RP Y somewhere on the net does not work on Tuesday. And then we need a process that makes sure X and Y fix it within our lifetimes. Even better, a real interop setup that runs once a night or something like that and tests "everybody" on the net who does OpenID.
• Yadis / XRDS-Simple harmonization. Why XRDS-Simple was never simply a revision 2 of the Yadis spec, I'll never understand. But regardless, going forward we need one document, not two.
• Something interesting with Attribute Exchange. I don't know what it would be, but there must be some interesting application scenarios? Right now we have this largely unused spec on our books. What do we need to do to make it used more/more useful?
• Security. We need to take a good look at whether we can turn some of the SHOULDs into MUSTs in the specs and thus get more secure.
• Non-repudiation. As the secret is symmetric in OpenID Authentication, OP and RP cannot prove to a third party whether the OP or the RP pretended that an authentication transaction took place (or not). It would be good if that could be unambiguously decided. For example, in LID, a time-stamped GPG-signed transaction can only have been created by the IdP, as only it has access to the private key. Can we have similar functionality for OpenID? This would raise the comfort level of commercial implementors as they could prove liability much more easily in court.
• Account recovery. If I create an account at some site S using OpenID X, but I later lose OpenID X (e.g. because I change jobs, because the provider went out of business, because I got kicked off the service, whatever), I can't access my account at site S any more. That's a non-starter and needs to be solved.
• Mobile user experience. Need I say more?
• Personal activity tracking. If I do 5 things at 5 different sites, but using the same OpenID, it should be possible for some piece of software to recognize that and give me some kind of aggregated view. (This use case is for me, as the owner of the identity, but one can come up with similar use cases for other people.) For example, that could give me the "year-end statement" of all the content I authored all over the web with the same OpenID.
• Advertising preferences. Let's say I'm in the market for a new bicycle but not a new car. Is there some way I could express that preference on my OP, and all RPs where I use the identity could realize that they waste their money showing me car ads, but that I'd love to see bicycle ones instead?
• Electronic vouchers. Why can't a site A give me an electronic voucher for something that I then can use at site B? Like the coupons that I get at the grocery-store checkout (in the US): "you just bought a flash light, here is a 10 percent off coupon for batteries." It might be almost as easy as agreeing on a particular field in attribute exchange. These are the kinds of use cases that could unlock a lot of investment money into OpenID ...
• Non-browser login. OpenID Authentication makes the assumption that the user's software is a web browser. It's hard to do OpenID from other types of software (e.g. RSS readers, word processors, ssh...) but it would be good if one could do it.

What's your list?

Update 13:18: http://mylid.net/mglcel suggests: "What about social networks storage on OpenID?" Sounds like a good idea, but perhaps a bit difficult politically. That shouldn't keep us from working on it, though.

17 Jul 2008 8:18pm GMT