Here is a picture of the authnapped OpenId form:Here is a picture of the original OpenId login:It is the user's decision to install and use Mozilla Lab's project "weave" or not. And this solves parts of the NASCAR problem. Why should the service provider suggest some OpenId providers using the NASCAR? Well, if he has a whitelist of trusted OPs then yes.But the OpenId-NASCAR is a cludge anyway.I think that there should be an XRD description of which authentication methods and providers and token formats and so on a service provider supports or requires. Then a client component - read Browser extension - could help the user to make a good decision and prevent phishing attacks and more.The user does not care whether the protocol is OpenId or Information Card or if the token format is SAML2 or what not. A unique user experience is desired. Ease of use is required. User consent is required. Security and Privacy need to be protected.

This should be "in the browser"! Secure by default. Privacy protecting by default.I guess I don't have to repeat that I prefer the Information Card metaphor and UI. A client component is a good thing and it should be ubiquious, build-in but replacable and configurable at the user's choice.

Identification, authentication and claims/attribute transfer is not the primary service provider's interest. Those tasks should be moved outside of the website's code into an authnapping module of the user's browser.

Friday, July 03, 2009

The Higgins Project, namely Markus Sabadello, created an Information Card Selector that runs on the iPhone. Due to Apple's benevolent dictatorship which prevents extensions to the iPhone's webbrowser this selector uses a custom URL-scheme to launch the selector from a web page. Details can be found here.

I adapted the xmldap relying party to output the new URL-scheme when the user-agent contains "iPhone" or "iPod".