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?
Wednesday, October 15, 2008
Information Cards with XRDS
Subscribe to:
Post Comments (Atom)
2 comments:
Interesting, though keeping with the current UX convention, I would have expected the link to the XRDS would have been put on the "purple i" image, and then clicking it would have invoked the selector to parse the RP policy. It seems strange to drag a random card (which may or may not fit the policy) as a means of triggering the selector.
Regarding "random card": Yes, but I see this as a limitation of my current implementation only. A better implementation could allow only those cards to be draggable that match the rp-policy. Another thing that is missing is that the sidebar content is not updated - it is just a list of my cards without reflection of the rp-policy. I need to improve that, true. But this is an issue of my sidebar sub-project and of my drag-and-drop sub-project.
What I wanted to show here is that XRDS might be better suited to achieve our goals than the html-object-element. And this way we can begin to integrate with other schemes that use XRDS too. In the end the browser add-on should become an integral part of the browser on all platforms. As I said in my post: The purple Information Card icon should be shown when Information Cards are applicable. But maybe this should be a task for the browser add-on and not for the relyingparty. Of course: nobody can stop an RP to show an information card icon and when clicked the RP returns a document with the mime-type of - let's say - "application/xml+information-card-policy" that the add-on digests.
Post a Comment