Firefox XRD Extension II

I just uploaded a new version of the XRDS extension for Firefox and a version of the openinfocard extension that uses it.

When the extension xrds_pageinfo.xpi is installed then the openinfocard extension shows the list of cards that where used at this site. Hm, to be more precise: The list of Information Cards is shown of which a record of usage is stored in the cardstore. If you use the new "delete privacy data" feature of the openinfocard extension then no card usage is shown.





Also available in other languages than German.
have fun
Axel

Firefox XRD Extension

Even so progress is slow sometimes...
Sometimes things actually move forward.
Based on the discussion at IIW and the former posts I started to write an extension for Firefox that allows users to see the XRDS provided by a site.

I see this as a further step to get IDentity In the Browser. But not only "openid in the browser" but much more.
First let's see how this looks.

 

Even if you have this new "xrds_pageinfo.xpi" extension installed and visit a site that provides xrds then there is at first not much to see. The site's XRDS is not visible to the user. And that is good as it is. The normal user is not interested in some xml file. The services described in the file matter.

Well. All my new Firefox extension currently does for the user is to show just that xml. Click on the favicon of the site and you will see something like this:

 

But there is more to come and there is more under the hood. The extension implements a component in javascript that allows other extensions to access the discovered XRDS and add/remove handler for services defined in the XRDS.

The current interface definition for the component is:
[function, scriptable, uuid(13e630b8-3f41-456b-ae26-c30b201c8f99)]
interface IXrdsServiceHandler : nsISupports
{
        boolean handle(in nsIDOMElement service, in nsIDOMDocument doc);
};
           
[scriptable, uuid(DDD9BC02-D964-4bd5-B5BC-943E483C6C57)]
interface IXrdsComponent : nsISupports
{
  void addServiceHandler(in ACString xrdsServiceType, in IXrdsServiceHandler aXrdsServiceHandler);
  void removeServiceHandler(in ACString xrdsServiceType, in IXrdsServiceHandler aXrdsServiceHandler);
  
  IXrdsServiceHandler iterator(in ACString xrdsServiceType);
  long getHandlerCount(in ACString xrdsServiceType);
  IXrdsServiceHandler getHandlerByIndex(in ACString xrdsServiceType, in long index);

  void addXrdsForSite(in ACString site, in AUTF8String xrds);
  AUTF8String getXrdsForSite(in ACString site);
};

This interface definition will change. But after I have integrated this into the openinfocard identity selector and after feedback from the other XRD-enthusiasts and perhaps integration into "openid in the browser" I expect something stable no so far away.

What next?

• provide some useful GUI
• it should be possible to click on a button and this will retrieve the privacy policy of the relying party or openid consumer if that service is defined by the XRDS.
• click and the Information Card selector starts and your chosen claims will be send to the RP.
• click and your openid attributes are retrieved and provided (without stealable credentials being involved).
• click and the browser opens the page where you can edit your data.
• click and the browser opens the page that lets you terminate the relation to this site.
• click and you can present your voucher.
• click and you are a new customer with verified claims.
• integrate with openinfocard id selector
• integrate with IDIB
• standardize all this
  • standardize service types
  • standardize this usage of XRDS for relying parties, openid consumers, webshops, whatever
  • There are many open questions. Implementing this and defining service types etc is fruitless if there is no (industry) standard.

I hope that I can work in the OASIS TC(s) relevant to this. Currently it looks like joining is next to impossible. I spare you the details.

I would like to end with something positive... So please find the Firefox extension here. Please send suggestions to
Happy Xrd-ing. -Axel

Pamela Dingle Speaks

Join veteran Experts Conference speaker Pam Dingle as she shares tips and tricks on how to achieve 'enlightened bottom-up' Identity Management. Pam believes that, as long as you start with a few simple overarching strategic principles, identity management can be 90% tactical. Pamela will use her professional IdM experience to show how the right selection of point solutions in the enterprise can make a world of difference, providing strategic agility to the business while pre-emptively reducing complexity for the future. Look for ILM, Federation and CardSpace to be key technology players in this talk, complete with real-life examples that tie it all together.

The Experts Conference, March 22-25, 2009 in Las Vegas, NV presents her talk "The Survivalists Guide to Identity Management".

java again

I got a new computer and tried the openinfocard id selector with it; but Boom the Java code did not run. Hm, I forgot to install a new version. Preinstalled was some Java 1.4 version... I installed Java 1.6 update 10 and tried again, but again it failed. Ahh, the new java plugin for Firefox hit me again.
Error calling method on NPObject! [plugin exception: java.security.AccessControlException: access denied (java.security.SecurityPermission getPolicy)]

I had to set HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\1.6.0_10\UseNewJavaPlugin from 1 to 0 to disable the new plugin.

After that the openinfocard selector worked again.

Sun promised to fix this in Java 1.6 update 12 but there is no early access version available...
Another bug in the new plugin is that it does not implement the instanceof operator for Java objects.

Kenneth from Sun suggested a workaround: Have to change
if (!(bootstrapClassLoader instanceof java.net.URLClassLoader)) {
to
if (!(bootstrapClassLoader.getClass().isInstance(java.lang.Class.forName("java.net.URLClassLoader")))) {

For this bug there is not even a promise to fix it... Well, thank you SUN for making my life interesting; NOT.

Information Cards for Google Apps

Information Cards are an industry standard that enable people to maintain a set of personal digital identities.
Information Cards are like cards in your wallet. Each one defines a relationship between you -the cardholder- and the card issuer -the identity provider. They provide a way to transfer claims/attributes from the identity provider to a relyingparty. Information Card selectors are available for all major operating systems and major browsers. To learn more about Information Cards please visit the Information Card Foundation.

Having provided support for "SAML Single Sign-On (SSO) Service for Google Apps" not so long ago Google is now proud to present support for Information Cards for Google Apps.
The step from "SAML Single Sign-On (SSO) Service for Google Apps" to Information Card support is actually quite small. This is due to the fact that all Information Card selectors are token agnostic that is: They don't care which type of token is transfered from the identity provider to the relying party. Therefore we choose to use SAML assertions that are used in "SAML Single Sign-On (SSO) Service for Google Apps" too.

Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content.

Google Apps offers an Information Card based claims transfer that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications like Gmail or Google Calendar. Using the Information Card model, Google acts as the relying party and provides services such as Gmail and Start Pages. Google partners act as identity providers and control credentials and other information (claims/attributes) used to identify, authenticate and authorize users for web applications that Google hosts. Google wants to point out that it is hard to overestimate the security gains for our partners. By using the authentication methods implemented in e.g. Windows Cardspace partners can use Kerberos, X509 and self-issued cards to authenticate the user to the security token server; thereby leveraging existing corporate infrastructure to access Google Apps through this new services.

There are a number of existing open source and commercial identity provider solutions that can help you implement Information Cards with Google Apps.
It is important to note that the SSO solution only applies to web applications. If you want to enable your users to access Google services with desktop clients such as Outlook—for example, Outlook would provide POP access to Gmail—you will still need to provide your users with usable passwords and synchronize those passwords with your internal user database using the Provisioning API.

The Google Apps with Information Card is based the "Identity Selector Interoperability Profile V1.5". Information Cards are supported by several widely known vendors. Visit the Information Card Foundation to learn more.

Understanding Information Card based usage of Google Apps

The following process explains how a user logs into a hosted Google application through a partner-operated identity provider service.

Figure 1: Logging in to Google Apps using Information Cards


This image illustrates the following steps.

1. The user attemps to reach a hosted Google application, such as Gmail, Start Pages, or another Google service.
   Google presents a page with the purple-i that denotes that Information Cards can be used here. The RelayState parameter containing the encoded URL of the Google application that the user is trying to reach is transferred to the Google ACS as a form parameter. This RelayState parameter not transferred to the partner. Each google app requests at least one claim that is identitcal to the applications base url e.g. "http://calendar.parityapps.com/".
2. The user clicks the purple-i icon
3. The cardselector starts and the user selects her information card e.g. the managed card issued by Parity. The card selectore sends the security token request to the partner
4. The partner parses the request and authenticats the user using one of the supported authentication methods Kerberos, X509 certificate, self-issued card or username and password
5. Partner generates SAML assertion (security token).
6. The browser posts the security token and the other form element's values to the Google ACS
7. Google's ACS verifies the SAML response using the partner's public key. If the response is successfully verified, ACS redirects the user to the destination URL.
8. The user has been redirected to the destination URL and is logged in to Google Apps.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I hope to read an anouncement like the fake one above by Google soon ;-)

Internet Explorer Mobile 6 Geneva? Not!

Microsoft just announced the new version of Internet Explorer Mobile 6.
The feedback on the PIE blog sounds mostly disappointed.

I guess that the new version still neither has CardSpace support.
I would welcome a mobileCardSpace even if it would have no self-issued card support.
Or maybe we should make the PKCS#5 algorithm in ISIP optional? Self-issued cards are the main reason we don't have mobile selectors.

Sad.

No XHTML at Information Card Tile Page

Is it only me who finds it anoying that Microsoft over and over again produces example pages that have very very illegal (X)HTML code?

The example page for the Information Card Tile has yet several errors that occure when one uses a framework to create HTML pages that simply does not work well.
One should think that Microsoft's programmers have access to tools that produce valid code?! Or maybe all the Micorsoft tools and frameworks are so that they produce invalid code when you include one page into another?

Bad example. Although I like the Information Card Tile. Even though I would implement it in another way. Some time ago I came up with the same idea but did not implement it because that would have been "not standard". Well, now it seems we witness the birth of a new standard.

I would implement the Information Card Tile á la microformats by using the class attribute. I would add a special class to the HTML-image tag to denote a tile.

If the RP does not want a tile when no selector is installed then:
Example: <image class="InformationCardTile" src="" id="the-ppid" alt="invisible"/>

If the RP does want an image when no selector is installed then:
Example: <image class="InformationCardTile" src="http://rp/image.png" id="the-ppid" alt="Purple Information Card Icon" onclick="submitForm()"/>

The selector would then overwrite the src-attribute when the card with the PPID "the-ppid" exists and add an onclick-handler that starts the selector or sends the card if the user has chosen to always use this card.

Equifax Unveils Online Identity Card

ATLANTA, November 13, 2008 - Equifax Inc. (NYSE: EFX) unveiled today the Equifax online identity card or I-Card, with a beta test of a first-of-its-kind digital identity management solution that is designed to make online transactions easier and more secure for both consumers and businesses....

Read the whole story at Parity's website.

IIW2008b: XRDS for OpenID and Information Cards

We will have a session this morning about XRDS and OpenId and Information Cards.

The IIW2008b wiki has an initial page about this topic.


Please come and let us define something useful.

"Big Dog" Wow!

Amazing!

Visit Boston Dynamics for the full story.

Common Browser Add-On

The current version of the openinfocard identity selector now uses the same browser add-on code as DigitalMe (revision 2525 of IdentitySelector.js).
Although there are some additional features like the status-bar icon and the XRDS support.

XMLDAP XRDS

The XMLDAP relying party is now updated to provide XRDS data.

Notice the Information Card icon in the lower right corner in the status-bar of the browser.

You can start the card selector either through the sidebar - by dragging a card to the main window - or by clicking the Information Card icon. You need the latest version of the openinfocard id selector.

You may be wondering what the difference between the next and the previous image is?
I created a second card and used it at the xmldap relying party too.
The new claims were added to the previous set of claims. The claim "locality == Berlin" is new.

This image shows that the claim set was cleared. The relyingparty party has forgotten the privacy data after the "Clear privacy data" button was pressed.

THIS IS THE USER EXPERIENCE YOU WANT. DEATH TO USERNAME/PASSWORD.
(learn more)

Information Card XRDS with Information Card Icon

Please note the small Information Card icon in the status-bar in the lower-right corner of the browser window.

If no Information Cards are accepted by the site then the icon has a little red cross.

If Information Cards are accepted by the site then the Information Card icon is shown.

You can click on the icon to start the identity selector.

Information Cards with XRDS

In former posts in this blog I stated that I find the use of the HTML object element for Information Cards "not optimal". The main reason is that the object element is intended to provide a means to render media like Flash, PDF, videos, sound etc. The second reason is that Mozilla requires that object elements are handled by a plugin instead of add-ons (and plugins are platform dependant).

In other posts I described a way to use XRDS to eliminate the object element.
Now, finally, I found some time to implement this in the openinfocard information card selector and the xmldap relying party.

First, here is how this looks.

The user surfs to the relying party.

She opens the card selector in the browser's sidebar (Crtl-Shift-i).

She drags a card onto the main window and the card selector starts.

The relying party now shows the posted token.


This is really cool. No more javascript kungfu to detect the card selector.
Detecting the presence of the selector and acting appropriately is not that easy for a relying party. Now this task is simply not there. No more hiding of the missing plugin warning.

Well, there is certainly room for improvement. The openinfocard selector in the current (unpublished) version does not indicate to the user that claims are acceptable at the RP. But I can change this easily. My current favorite to indicate this is a floating Information Card Icon in some corner of the browser window but maybe a more subtle way is more appropriate. A small information card icon on the right side in the address bar or somewhere in the bar at the bottom of the Firefox window??? Or the sidebar could open automatically...

How does this work?
1) The relying party HTML contains a HTML-Link element that points to a xrds file that is retrieved by the openinfocard Firefox add-on.
<link rel="xrds.metadata" href="?xmldap_rp.xrds"/>
In this example the href is a URL relative to the current document but the href can be absolute too.
2) The openinfocard add-on retrieves the xrds.metadata document.
<XRDS xmlns="xri://$xrds">
  <XRD version="2.0" xmlns="xri://$XRD*($v*2.0)">
    <Type>xri://$xrds*simple</Type>
    <Service>
      <Type>http://infocardfoundation.org/policy/1.0/login</Type>
      <URI>https://w4de3esy0069028.gdc-bln01.t-systems.com:8443/relyingparty/?login.xml</URI>
    </Service>
    <Service>
      <Type>http://infocardfoundation.org/policy/1.0/registration</Type>
      <URI>https://w4de3esy0069028.gdc-bln01.t-systems.com:8443/relyingparty/registration.xml</URI>
    </Service>
    <Service>
      <Type>http://infocardfoundation.org/service/1.0/login</Type>
      <URI>https://w4de3esy0069028.gdc-bln01.t-systems.com:8443/relyingparty/link.jsp</URI>
    </Service>
    <Service>
      <Type>http://infocardfoundation.org/service/1.0/registration</Type>
      <URI>https://w4de3esy0069028.gdc-bln01.t-systems.com:8443/relyingparty/registration</URI>
    </Service>
  </XRD>
</XRDS>

2) The openinfocard add-on retrieves the document for the service of type "http://infocardfoundation.org/policy/1.0/login".

This document is simply our old foe the object element:
<object type="application/x-informationcard" name="xmlToken">
  <param name="privacyUrl" value="https://w4de3esy0069028.gdc-bln01.t-systems.com:8443/relyingparty/?privacy.txt"/>
  <param name="requiredClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"/>
  <param name="optionalClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender"/>
  <param name="privacyVersion" value="1"/>
  <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion"/>
</object>

Instead of the object I could have used a relying party issuerPolicy document but I wanted to keeps things simple.
4) When an information card is dragged onto the main browser window the login policy is parsed and the selector is called with the parameters. The add-on could even call CardSpace...
5) The security token from the card selector is posted to the service of xrds type "http://infocardfoundation.org/service/1.0/login".
6) The relying party interprets the token and returns nothing.
7) The openinfocard add-on directs the browser to the login-service URL
8) The relying party can show the the claims to the user or whatever it thinks it is appropriate with the new claims information (e.g. new payment options).

What do you think about this?

Web 2.0 Expo Europe Next Week in Berlin

This morning I found an advertisment for next week's Web 2.0. Expo Europe in my daily newspaper.
I find it interessting that the organizers find it money well spend to have an ad in a "normal" newspaper. A quarter of the first page of the business section costs probably some money.

I will not attend the conference but will probably visit the expo. Although I would like to go to the conference too. There are some interesting talks and session. My brazen request for a blogger/press pass was rightly declined. See you at the Web 2.0 Summit in November and of course the Internet Identity Workshop 2008b.

openinfocard for Firefox >= 3.0.2

Andrew Hodgkinson found a workaround for the latest Firefox hickups. Mozilla removed the non-standard two-parameter eval( statement, scope ) function which was used by the Firefox add-ons that implement identity selection through Information Cards. SUN's java problems that the openinfocard id selector experiences continue to bug us. With Firefox 3 the openinfocard selector is really usable only for managed cards because the java part of the selector is mainly used to issue self-issued tokens. Managed cards are handled by javascript code.
You can download the latest version of the openinfocard selector from the project's repository.
I still recommend to use Firefox 2 until SUN and Mozilla fix the java problems.

Bugzilla@Mozilla – Bug 457068

The number of bugs in Firefox and the Firefox Java plugin that affect the openinfocard id selector increased in the last days/weeks. Not funny.

- eval(..., scope) regression
- javascript instanceof not working with Java classes
- AccessControlException for java based Firefox extensions
- javascript array constructor not working with Java classes
- window.java is sometimes defined but sometimes not

Sun says they can not fix the java plugin for java 6 update 10...

Aaargh.

Maybe it is time to build Information Card support into Firefox and other Mozilla applications directly?! This is worth a post on its own.

Certified Secure Software Lifecycle Professional

"(ISC)2 launched a brand new certification program designed to validate secure software development practices and expertise and address the increasing number of application vulnerabilities."
I hope that the future CSSLP knows that software needs external authentication.
Pamela was preaching this to us at DIDW2008 and it is true.
When a company plans to buy software then we need requirements for external authentication in the request for proposal. This is a must!
And the software should understand claims because "Claims Change Everything!".


External authentication gives you more security because you can choose an established authentication software for authentication in contrast to having to rely on a home-grown authentication module by a database vendor or search engine maker.

Says Axel Nennker, CISSP, CISA, Security Preacher

Please contact the information card foundation to learn more about Information Cards and claims!

Firefox 3.0.2 breaks ID Selector Browser Add-Ons

The current update of Firefox to version 3.0.2 breaks the Firefox ID selector browser add-ons. This does affect the openinfocard and the CardSpace4Firefox selector. I have not tried it but I assume that the other Firefox add-ons (Bandit/DigitalMe) are broken too. Thank you Mozilla (again).

I guess that eval( statement, doc ) stopped working. In the end the capturing of form-submit-events and the html-object-value-getter do not work due to this.

I am trying to fix this ASAP.

Drag & Drop Login

On Monday I published a version of the openinfocard identity selector that allows drag & drop selection of information cards at a relyingparty.

While this is NON-standard I would like it if some relying parties would jump onto this train. And of course I hope that this or something like it will become Standard.

Some thoughts about this:
Why: It is cool. You want to drag a card onto the relyingparty.

What is the problem with the current standard? The object tag has no width and height. Although the object-element was originally intended by the W3C to handle media data like video, flash, pdf, etc this was/is not the way the object tag is intended to be used by ISIP and the ISIP Web Guide as defined by Microsoft. Here the object-element provides information about the required and optional claim, the token type etc but it does not occupy space on the web page. This means that there is nothing you can drop a card onto.

Solution: Introduce a parameter to the object-element that signifies the HTML element where a card can be dropped on. The identity selector then adds drag&drop handlers to this HTML-element and these handlers trigger the identity selector when a cardId is dropped on the HTML-element with the right icDropTargetId.
This is a 1-to-1 relationship between object-element and droptarget-element.
The drop target is inside a form that gets submitted when a cardId is dropped.

Technical detail: The thing that is dragged has the mime-type "application/x-informationcard-id". If you are a card selector outside of Firefox then all you need to do to participate in this is to create a drag-"thingy" with this mime-type. The openinfocard id selector will accept only things dropped onto the drop-target with this mime-type. Easy, isn't it?!

There is of course room for improvement. We could aggree on dragging a whole card of mime-type "application/x-informationcard" and compare the tokentype and supported claimtype before accepting the dragged card...

Compability with CardSpace: The icardie.dll does not care if there are extra parameters for the object-element. Your relyingparty works with CardSpace when this new parameters is present. There is just no drag&drop feature.