ongoing · OpenID

The Real Problem · Of course, out there in the enterprise space where most of Sun’s customers live, they think about identity problems at an entirely different level. Single-sign-on seems like a little and not terribly interesting piece of the problem. They lose sleep at night over “Attribute Exchange”; once you have an identity, who is allowed to hold what pieces of information about you, and what are the right protocols by which they may be requested, authorized, and delivered? The technology is tough, but the policy issues are mind-boggling.

While it’s true that OpenID doesn’t really deal with attribute exchange (and usage, etc — yet) I think what it really does is standardize a user-controlled request process. So… just like restful proponents seek to standardize the semantics of acquiring resources and interacting with them, OpenID provides a simple, standard authentication channel. An application could be locally configured to only accept OpenIDs from certain IdPs (e.g. a University’s OpenID server, federated partners, AOL) or have some kind of assurance checking mechanism, but that’s optional. Whereas, for the common internet case of just wanting a persistent handle so people can come back to the same account again (low assurance).

In terms of attribute release – just like DRM, I have yet to really see a workable attribute usage and release scheme that doesn’t require you to trust recieving parties anyway. And the OpenID approach of having the user approve the IdP’s release of particular attributes seems just as reasonable (and much more scalable) than an institution trying to build a policy with tiers or permissions as to who can get data. Requiring user release seems to solve lots of problems, actually.

Strange love for passwords

Now, I’m not going to speculate too far into the future, to a time when Visa displaces the DMV or passport agency as issuer of authoritative international credentials for every kind of identification and authentication. However, there are no other entities that have Visa and MasterCard’s topical ubiquity and influence.  They’ve picked their technology, and if it isn’t in your hands now, it will be soon. It might not fit corporate authentication or private transaction use cases perfectly, but as noted in RFC 1925, “given enough thrust, pigs fly just fine.”

Actually, in an end game, I could see credit card companies taking over as the issuer or vetter of id tokens. Of course, I’ve always thought it made more sense for a government issued id to combine the token and attribute portions of a passport, driver’s license, all those annoying shopping loyalty programs, AAA card, and any credit accounts you may have. Sort of a universal card. If the tokens were appropriately encrypted and obscured, with some kind of user-controlled release I think we could shift the convenience/privacy tradeoff far enough that people would go for it.

Although — if you really wanted to be ambitious with your identity system, once you had a smartcard based system — maybe an access control vendor, or discount program could get the mass deployment necessary, you could cut the credit card companies out of the middle. At least for debit-card like transactions it seems you could process for 1% or so and still make a tidy profit. Even credit lines have to be highly attractive given the number of parties who want to get in the game.

Netvibes Promises Cross-Platform Widget Compatibility Today at the Future of Web Apps conference in London, Netvibes founder Tariq Krim announced that their upcoming “Coriander” release will do just that. Once launched, any widget created for Netvibes, Krim says, will work on the Vista, Google, Mac and Opera platforms as well. Support for Yahoo Widgets and other platforms will follow soon after.

Netvibes writing an adaptor for their widgets looks great. I increasingly wonder if uPortal should ship with a JS widget adaptor for one of the major APIs (though I guess we should right for say Google, and pick up Netvibes widges for free Then the portal container can store the preferences, but bootstrap the widget engine to render the content. Leverage all that interesting functionality the big AJAX portals are building

I was reviewing the excellent work Unicon’s Gary Thompson has done in developing personas related to uPortal (really they seem applicable across Higher-Education), which jogged my to write about some thinking: leveraging well-developed UE personas to build a suite of synthetic test-data.

User Experience is often not fully integrated within other aspects of the software development lifecycle, due to user experience’s ambiguous relationship with the “hard-types”. One aspect that stands out however is the similarity between UE personas and good sets of synthetic test data. Both seek to identify, quantify, and provide a means for verifying functionality against common scenarios and edge cases. Also, both are a lot of work to do well.

In work within the context of the uPortal project — I’ve begun to wonder whether involving the UE personas in the generation of seeding our test data might have some nice synergies.

Benefits:

• Focus developers on UE personas during testing
• Provide iteritive development & refinement of personas and test data
• Provide common language for uniting UE tasks & developer edge-cases
• More tightly integrate functional and UAT testing scenarios

In the case of uPortal, very simple test data has always shipped with the project, generic accounts for “student” “admin” “faculty” and the like. How much richer would our demonstration and design capabilities be if we actually had an accounts for Owen Oldschool which developers could test against that defaulted to larger fonts, and had a UAT script that tested the contextual help?

In open-source in particular, where there’s been a historical disconnect between the design/UE community, it seems like trying to integrate out tools, processes, and language could show great benefits.