Saturday, May 31, 2008
I should note that the web-based card selector can work with existing IDP's (since we're doing WS-Trust, after all) and with current RP's with Infocard web form/object login with a specially created bookmarklet. This approach opens the door to even current browsers which do not support HTML5. But more on this later.
Something we've been working on is the ability to create a web-based card selector which will work in situations where a full card selector is not available or appropriate. Since selectors are not yet ubiquitous and inappropriate in many tactical situations, we are working on using a HTML5 based approach to enable an Infocard/CardSpace-based enterprise to work with standard web browsers.
The major changes in HTML5 which allow for this to occur are offline caching (HTML Manifest), the navigator.registerProtocolHandler action, and the DOM/Session storage capabilities. For more information, see Mark Finkle's excellent blog on Firefox 3's offline features and the WHATWG HTML5 Draft Specification for the rest. With these capabilities to be included in future web browsers, we can now assume that the client browser:
- Can cache URL resources and seamlessly serve them when connectivity to the IDP cannot be established
- Can route particular protocol requests from arbitrary RP's to a registered IDP web app
- Can (persistently) store a user's preferences and settings locally, where information regarding trust and disclosures can be held.
With these capabilities, one can begin to see how a web app could operate as a client card selector:
- After provisioning occurs, the user access an RP with a login link which specifies the target protocol and any parameters needed for login, e.g. infocard://respondToUrl=[rpurl]&requiredClaims=[claims]&optionalClaims=[claims]
- The browser prompts the user to select a registered webapp to handle the invocation, which roughly parallels card selection. Upon selection of the IDP offline app registered in step 1, the browser redirects the user to the cached application. (Note that per the WHATWG draft specification, no information necessarily goes back to the IDP at this point)
- The cached web app parses the URL encoded information provided in step two and previews the requested claims to the user. This is analogous to the pre-retrieval step of the Infocard ceremony. The user may select/deselect optional attributes or cancel the transaction at this point.
- After review, the user chooses to submit the token, which is posted to the RP site in the same fashion as current card selectors (HTTP POST with a xmlToken value).
This approach seemingly solves the problem of a lack of card selectors and lightweight clients assuming that all major browser implement HTML5 (which appears to be the case). The above approach actually works as demonstrated by our proof of concept which uses only Firefox 3 or any browser with Google Gears.
The registerProtocolHandler (and possibly even the MIME handler) seem to have a number of possibilities within the federated identity communities. As demonstrated above with the Infocard scenario, this can address the vexing "Where are you from?" problem which plagues web-based federated identity solutions including OpenID. Omitting the RP from the redirection phase via the web app selector and a carefully crafted offline web app should do wonders to reduce spoofability and increase usability.
While this is a big step to lightweight identity selectors, it does lack a number of the nice features available in a full card selector:
- Cannot provide "clues" regarding the applicability of registered web apps (such as disabling cards/webapps which are inappropriate for the required claims)
- Cannot easily integrate with the OS for things such as public/private key creation, thus this is clearly aimed toward managed card with browser-friendly authentication.
Below is a simple web-based card selector provisioning data flow, though I forgot to put in the card metadata exchange in step 4.
The offline cache is much more useful than just for the protection of the user privacy; once offline tokens within Infocard become possible, this approach should still be very viable. I have a screencast of our demo and I'll update this post when I get around to uploading it to YouTube.
Thursday, May 29, 2008
In a past life I wrote automation controllers for large facilities. Now, I'm obsessed with needlessly automating my house (since it's my first). Thus, I present to you, my latest in ridiculously over-engineered automations:
The iPhone Garage Door Opener
Why? Cause it's cool to be able to press a button on my phone and have my garage door open. That, and, I have a horrible habit of leaving my garage door open all night for anyone to access, and now I can create a script to remotely close the door at a given time.
The stuff I bought consists of an NPort 16 port serial server (5610, if I remember) and an National Control Devices ProXR 4 Relay, 8 Input serial controller. To sense state, I included a garage door contact sensor with input into the ProXR.
On my MacPro, I have Tomcat running with a servlet which responds to the AJAX calls from my little iPhone-customized JSP page. The UI updates every 5 seconds, updating the door state and the current temperature in the garage (since a temperature sensor comes on the ProXR). So now I can use my iPhone to control my garage (which is almost useful)!