Tuesday, December 30, 2008

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

Friday, December 05, 2008

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

Tuesday, December 02, 2008

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".

Tuesday, November 25, 2008

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.

Friday, November 21, 2008

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 ;-)

Tuesday, November 18, 2008

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.

Thursday, November 13, 2008

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.

Wednesday, November 12, 2008

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.

Sunday, November 09, 2008

"Big Dog" Wow!

Amazing!





Visit Boston Dynamics for the full story.

Friday, November 07, 2008

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.

Friday, October 24, 2008

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)

Thursday, October 16, 2008

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.

Wednesday, October 15, 2008

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?

Tuesday, October 14, 2008

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.

Tuesday, September 30, 2008

openinfocard for Firefox >= 3.0.2

openinfocard project logoAndrew 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.

Friday, September 26, 2008

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!

Thursday, September 25, 2008

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.

Wednesday, September 24, 2008

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.

Monday, September 22, 2008

Drop into a Site

I just uploaded a new verion of the XMLDAP RP source code and a new version of the openinfocard card selector.

You still have to compile you own version of the XMLDAP relyingparty because the current server still lacks a valid cert.
Signature validation of an newly imported card seems to fail too everytime. Sorry. Working on that (too).

Now for the new stuff. You can now display a list of your Firefox Identity Selector's cards in the browsers sidebar by pressing Ctrl-Shift-I. When you then drag a card onto the Information Card Icon the identity selector gets started and you can select a card to generate a token for the relyingparty. Cool.

It would be even cooler if the dragged card was preselected but for this I have to change the interface between browser add-on and identity selector.
The current interface for the getBrowserToken function is:

    GetBrowserToken: function (
issuer , recipientURL, requiredClaims, optionalClaims , tokenType,
privacyPolicy, privacyPolicyVersion, serverCert, issuerPolicy);


I will just add the new parameter cardid to this call. And while I am at it I will introduce a new parameter sslMode. "sslMode" tells the selector whether the browser thinks that the serverCert is an extended validation certificate or not. Adding more and more parameters to the call does not seem optimal but the xpt interface in mozilla code only allows simple and some more types. I can not define structs/records etc. Theses changes to the API affect the other Firefox extension too. I have to change CardSpace for Firefox too. And maybe others will make use of this API too? (Another subproject I don't have time for: convert the DigitalMe/Bandit/Higgins-Firefox selectors into components that use this API. Or another API we might agree on in the "Browser Integration Working Group" in the Information Card Foundation.)


Drag a card onto the relyingparty's icon.


How does it work: Well, I had to make another change and add a new parameter to the HTML object of type application/x-informationcard.

<form method='post' action='./infocard' id='infocard' enctype='application/x-www-form-urlencoded'>
<img id="icDropTarget" class="droparea" src="./img/card_off.png" alt=""
onmouseover="this.src='./img/card_on.png';"
onmouseout="this.src='./img/card_off.png';"
onclick='var pf = document.getElementById("infocard"); pf.submit();'/>


<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="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion"/>
<param name="privacyVersion" value="1"/>
<param name="icDropTargetId" value="icDropTarget"/>
</object>
</form>


The new parameter "icDropTargetId" signifies the element where information cards can be dropped onto. The img element in this example has this id. If the element is inside a form than it is submitted by the dropped information card. Simple!

Enjoy. (with Firefox 2 please)

Wednesday, September 17, 2008

Microsoft PDC2008 - Identity

Claims-Based Identity: A Security Model for Connected Applications
Presenter(s): Kim Cameron, Stuart Kwan
Claims-based security is the underpinning of many applications, services, and servers. This model enables security features like: multiple authentication types, stronger authentication on-the-fly, and delegation of user identity between applications. Learn how to use this model in .NET, how it integrates with Active Directory, how it works across platforms, how it works with existing applications, and how we use it at Microsoft.

Tags:
Advanced, Cloud Services, Identity

Live Platform: Identity Services
Presenter: Jorgen Thelin
The Live Platform enables developers on any platform to choose the identity integration model that best enables their scenarios, including: web or client authentication, delegated authentication, or federated authentication. Learn how to build seamless, cobranded, and customized sign-up and sign-in experiences.

Tags:
Expert, Identity, Live Platform
Securing Your Service Using the Federated Identity Services
Presenter: Justin Smith
Learn how identity services can quickly add authentication and authorization to a service, as well as federate with other identity systems, making it possible for a service to seamlessly use corporate credentials for access control.

Tags:
Advanced, Cloud Services, Identity
Connecting Active Directory to Microsoft Cloud Services
Presenter(s): Lynn Ayres, Tore Sundelin
Learn how to augment your existing IT infrastructure with Microsoft Services. Manage and secure end user access to cloud services using your existing investment in Active Directory. Enable end users to access cloud services through existing Active Directory accounts, the same way they access your intranet-hosted software today. Hear how to enable existing software to use new service capabilities without re-writes, and do it all through the use of open and standard protocols.

Tags:
Advanced, Cloud Services, Identity
"Zermatt": Enabling Next Generation IdentityThe security demands of applications continue to evolve in the face of compliance requirements, new online threats, and SOA and cloud re-engineering. See how to use the "Zermatt" next-generation authentication framework and services and the claims-based identity model to enable single sign on, strong authentication, federation, and the ability to flow user authentication between applications. Find out how to use "Zermatt" with ASP.NET, WCF, Active Directory, and Windows CardSpace.

Tags:
Advanced, Identity
"Zermatt": Deep DiveIn this session we examine the architecture of "Zermatt" next generation identity technology, and how it can be customized and extended for advanced security scenarios. At the center of the discussion is the Security Token Service (STS), a core component providing authentication and identity services. Many applications will benefit from an embedded STS, and many scenarios will call for an STS that is built on a specialized user store.

Tags:
Expert, Identity
Windows CardSpace "2": Under the HoodWindows CardSpace provides a consistent, hardened sign-in experience that uses standard protocols and works with both thin and smart client applications. Learn about the features and architecture of the next version of Windows CardSpace.

Tags:
Advanced, Identity
Services Symposium: Enterprise Grade Cloud Applications
Speaker information pending.
Today, hosted applications do not offer many of the features that large enterprises expect related to identity, management, and data. See detailed examples of "enterprise grade" hosted application design. Learn how to implement a federated identity scenario, enable remote application management, and provide richer control of data storage.

Tags:
Advanced, Cloud Services, Identity


I guess that MS marketing decided that half of the sessions have to be tagged "cloud services". What I am missing: When will we have CardSpace for Windows Mobile?! Wouldn't it be nice to use all that fabulous cloud services from a Windows Mobile device?
And: No connection between SharePoint and CardSpace/Identity/Zermatt?

Intel Dude - The Burger Diet

Usually well informed sources hint that ID-TBD has more meanings than expected.

Monday, September 15, 2008

xmldap STS update

While the service at https://xmldap.org/sts/ currently has an outdated certificate (Sorry!) the code did improve nevertheless.
When you compile and install the code on your server then you can now create managed cards that have the RequireStrongRecipientIdentity and RequireAppliesTo elements set.

I will update the applications on xmldap.org after we have the valid cert again.
The openinfocard id selector was updated too to read and interpret the new element in managed cards.
Enjoy.

Friday, September 12, 2008

Firefox Java Plugin(s)

Have you ever wondered how Firefox finds the Java plugin on Windows systems? The reason you might start to wonder is that Firefox finds the plugin even when you installed Firefox after you had installed Java...
The trick is that Firefox - as long as you don't configure it not to do this - scans the Windows Registry.


If you experience problems with the new NPRUNTIME version of the Java plugin you can disable it like shown in the picture. This solves problems Java based plugins like the openinfocard id selector have with this new and improved Java plugin.

Please note that this is (somewhat) independent of Firefox. Even if you have an older version of Firefox the new plugin's bugs can hurt you if you have a recent version of Java that contains the new npruntime version of the Java plugin.

I recommend to disable the new npruntime plugin for Java in Firefox.

Tuesday, September 09, 2008

Common Misconception: Username/Password Tokens


People new to Information Cards sometimes think that Information Cards are used to transport username and password to login at a relying party....
Well, Information Cards could be used for that but this is a stupid idea.

First it is incomprehension. Then you start to think: "Why not. This could make the life of a relying party easier. They know how to handle username and password, so let's give it to them". Bad idea.

When you use the security token to transport username and password and you use nothing but username and password from the token then you are giving away the advantages of the whole concept.
There need to be changes to the RP's software to disassemble the security token anyway. When you accept this then you should accept that you can then use the security features of the token too. Each library that can disassemble the token can validate it too. It does not hurt to check the validity dates of the security token. It does not hurt to verify the signature of the security token. If the backend system is so old and inflexible that you must provide two strings for authentication then use a variation of e.g.: uid=PPID, pwd=public-key-base64 or uid=username, pwd=PPID or uid=first-8-bytes-from-PPID, pwd=8-bytes-from-public-key-hash-from-selected-but-fixed-positions. But you must check the signature. Only the owner of the private key could sign the security token and the private key is never transferred to the anybody. This is THE advantage compared to username and password. You can not forge the security token even if you know username and password.

Don't invent username/password-tokens. Don't do evil.

Misconception


When I was new to Information Cards I for some time believed that it is possible to use another cert for security token signatures than for the SSL endpoint. This is not true. I thought that this is a feature for the scenario when you host your STS at a webserver provider e.g. at https://openinfocard.org/ and you don't have access to the webserver's SSL key.
During the last days I was reminded of this misconception because https://xmldap.org/sts/ was down and I wanted to deploy the XMLDAP war files to openinfocard.org...
GoDaddy support told me that they can not give me the private key of "my" SSL cert. Bummer.
Without that key I can not issue security tokens. And there is no way to specify that I am using certA for SSL protection of the endpoint and certB to sign the security token. Hm. Maybe this should be possible in the "standard"?

Certs, certs, certs everywhere...

openinfocard and Firefox 3


There are currently issues with java in Firefox3 that prevent the openinfocard id selector to function reliably. For the time beeing: If you want to use/try the openinfocard id selector then please use Firefox 2.0.0.16.
Mozilla and Sun are changing the way java works in Firefox and this seems to be problematic. While I could work around some issues, there is no workaround for others. Using 6u10 makes things worse.
The current problems break all java extensions in Firefox3 that use the jar file loading technique recommended by the Mozilla Developer Center.

Über-Org

Yesterday at DIDW world I attended the morning part of the IDTBD workshop; an effort to create a new organisation that is an umbrella for e.g. OpenID foundation, Data Portability Project, Open Web or Information Card Foundation.
While I think that there are good reasons to try and the mission is honorable I think that this will not work as proposed. (I don't have access to the documents...)
In the end the whole thing is about money/funds, power/control and community. And not to forget IPR.

Something that might work, I think, is an organisation that is merely a helper organisation for the other organisations. It provides help to set up a non-profit org, to define bylaws, maybe secretary services, provide financial knowledge, fund raising knowledge, tax knowledge, HR knowledge etc. But this neworg has not power in the "real" organisation. It provides services to the real organistion by helping with issues the techies usually have problems with.
This would be not the big dream neworg but usefull.

Please don't mind this Kindergarden example. In Berlin there is an organisation called "Dachverband Berliner Kinder- und Schülerläden e.V." (DAKS). You could translate this as "Non-profit umbrella organisation of Berlin's Kinder- and Schülerläden". It provides this kind of services to its member Kinderläden. A Kinderladen is a Kindergarden that is run by the parents and not be the local government. Parents are no experts on how to run a Kinderladen and this knowledge gap is filled by the umbrella organisation's services. (The DAKS sees itself as a politcal representative of the 650 Kinderlädern in Berlin also).

Information Card Directory


There is still a lot to do to promote Information Cards. Fun Communications GmbH - member of the Information Card Foundation - has a directory of Information Card RPs and Issuers here at http://www.informationcarddirectory.com/.

We need to:

  1. put Information Card support in wide spread applications
    • Joomla
    • Wordpress
    • Mediawiki
    • ...
  2. put Informaton Card support into browsers
    • Firefox
    • Opera
    • Chrome
    • Webkit based browsers
    • Mobile browsers
    • ...
  3. put Information Card support into frameworks, APIs, middleware and widespread servers
  4. put Information Card support into mobile devices
    • cardstore on SIM/UICC/javacard...
    • card selector on phone while browsing on PC
    • ...
  5. Have major sites issue and accept Information Cards
    • Blogger.com
    • eBay / Paypal
    • Yahoo
    • LiveId
    • Press / Banks / Government Services
    • ...
  6. Improve Information Card usability
    • Faster startup of selector
    • Default card for a site
    • security token caching/reuse
    • even better privacy (U-Prove)
    • ...
  7. Educate / Inform / Convince
    • Users
    • Developers
    • Product managers
    • CISOs / CIOs
    • Privacy Advocates/Officers
    • Auditors
    • ...
  8. ...

Pick your priority...

Friday, September 05, 2008

Google Chrome


A quote from Wikipedia about Google Chrome:

Plugins


Plugins such as Adobe Flash Player are typically not standardised and as such cannot be sandboxed like tabs. These often need to run at or above the security level of the browser itself. To reduce exposure to attack, plugins are run in separate processes that communicate with the renderer, itself operating at "very low privileges" in dedicated per-tab processes. Plugins will need to be modified to operate within this software architecture while following the principle of least privilege.

Chrome supports the Netscape Plugin Application Programming Interface (NPAPI), but does not support the embedding of ActiveX controls. Also, Chrome does not have an extension system such as Mozilla-compatible *.xpi cross-platform extension architecture and thus XPI-based extensions such as AdBlock and GreaseMonkey can not be adapted to Chrome.

This means: no easy way to port the openinfocard id selector nor the browser add-on to Google Chrome.
Maybe I should take some time to revive my openinfocard plugin subproject...
Or I should start to put IDentity In the Browser and change the Chrome source code...?

Tuesday, September 02, 2008

Change

Whoever it may concern...

Since beginning of this month I am working for "Deutsche Telekom AG, Laboratories".
Good bye T-Systems, see you.

My desk did not change; Nor did my telephone number(s).
I expect some bumps with my email addresses. The T-Systems address will go away soon and it is still unclear whether I can keep my telekom.de email address. (Mysteries of Microsoft Exchange?)

My work will stay the same. Good!

Sunday, August 31, 2008

Happy Birthday

Happy Birthday.

Friday, August 29, 2008

Web 2.0 Summit + IIW 2008b


Palace Hotel
2 New Montgomery Street
San Francisco, CA 94105



Computer History Museum
Mountain View, CA


This is a nice combination. Meet me there. Suggestions for the weekend?!
-Axel

Tuesday, August 26, 2008

Firefox 3 Java Bug with openinfocard

Just filed a bug for Firefox 3 and Java 6 Update 10 RC.

I maintain the Firefox extension "openinfocard"
http://code.google.com/p/openinfocard/downloads/list
Since Firefox3 users experience an error message "ReferenceError: java is not
defined". Today I tried whether this error still occurs with
jdk-6u10-rc-bin-b28-windows-i586-p-21_jul_2008.exe and ran into the error
message.
"TypeError: invalid 'instanceof' operand java.net.URLClassLoader" here:
http://code.google.com/p/openinfocard/source/browse/trunk/firefox/components/TokenComponent.js#272
This works with previous version of java.

Reproducible: Always

Steps to Reproduce:
1. Install the Firefox extension into FF3. Save to disk, then install.
2. navigate to a site that uses Information Cards e.g.
https://wag.bandit-project.org/BanditIdP/index.jsp
3. Click on the Information Card icon
Actual Results:
An alert dialog opens with the error message "TypeError: invalid 'instanceof'
operand java.net.URLClassLoader

Expected Results:
No alert but the identity card selector window opens and you can create an
information card (self-issued) that you can then use to provide your claims
about yourself.

Internet Identity Workshop (IIW) 2008b


Computer History Museum
Mountain View, CA

The tag for this event is iiw2008b.

I for me don't have financing to attend (yet) but I recommend this event. Be there!

Friday, August 22, 2008

Kim, Architecture Journal, ICF


Vittorio wrote about issue #16 of the Microsoft Architecture Journal. The latest edition is all about Identity, Claims etc. And it contains an interview with the master, Kim Cameron, who mentions the Information Card Foundation as an example of the industry coming together to make this all happen.
Read it!

If you want to lean more about the Information Card Foundation please contact
Charles Andres, Executive Director
Information Card Foundation
56 Kearney Road
Needham, MA 02494 USA
+1-781 559 4223

xmldap / openinfocard new version


The openinfocard id selector now validates the signature of an imported information card and checks the validity dates of the signing certificate. The certificate chain and revocation lists are NOT checked. This is one feature that blocks an 1.0 release ;-)

Please make sure that you always use the latest version of the xmldap.jar (if you have an RP or STS that needs it) and xmldap.xpi (the id selector). In April I committed a version of the RP (xmldap.jar) to the svn repository that did not work with DigitalMe. I apologize for that.

Thursday, August 21, 2008

Information Cards: Unused (Security) Information

It seems that I have to make up for not posting while my new house was build...

Here is another post for today in the series (1,2,3) of posts around things you always wanted to know about Information Cards but never had the heart to ask.

Did you know that CardSpace does not use the Identity information in an identity enabled EndpointReference? Shocking.
Here is what I heard...

When you import a managed card from a .crd file there is something inside the file that is called the TokenServiceList that contains a sequence of TokenService(s) that contain an EndpointReference. This is defined in WS-Addressing and in our case extended to contain an element "Identity" from the namespace "http://schemas.xmlsoap.org/ws/2006/02/addressingidentity".
<Identity
 xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
 <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
  <X509Data>
   <X509Certificate>
MIICfTCCAeagAwIBAgIBATANBgkqhkiG9w0BAQUFADAqMQ0wCwYDVQQKEwRPU0lTMRkwFwYDVQQLExBJ
bnRlcm9wIEJvZ3VzIENBMB4XDTA4MDYxMTE2MTIxM1oXDTA5MDYxMTE2MTIxM1owSzENMAsGA1UEChME
T1NJUzEZMBcGA1UECxMQSW50ZXJvcCBCb2d1cyBDQTEfMB0GA1UEAxMWdGVzdC5wYW1lbGFwcm9qZWN0
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAz9qsJnJd/ZD8Fr/uGSojxMVoD53w28O14RLB
Hfm3scuFd9ypxy7KU8fOkDyOtKWoHqAVpPd/TRHIYiyRVorEyIiqQpbKCcqUd2YJM9nVxHuOHYvrVXRj
QAVV3Fu4Ncy22Tl+lJRJzWgcfc89aqFoyIv2tmqvAisRyNf6+1eppmcCAwEAAaOBkTCBjjAJBgNVHRME
AjAAMBEGCWCGSAGG+EIBAQQEAwIGQDALBgNVHQ8EBAMCBaAwKgYDVR0lBCMwIQYIKwYBBQUHAwEGCWCG
SAGG+EIEAQYKKwYBBAGCNwoDAzA1BglghkgBhvhCAQ0EKBYmT3BlblNTTCBDZXJ0aWZpY2F0ZSBmb3Ig
U1NMIFdlYiBTZXJ2ZXIwDQYJKoZIhvcNAQEFBQADgYEAIppR+riUA/cxJJBaNGslzoa297XMUqQelJ15
1UcGUWCqTxer2/b5nUG2TpmnA0/7CPCjE2t44st6MImB2tqDtI7DNSCKz19aNlhpoHa8MrCjPKHlDNIU
nqg3ZylCxbwm40G5NFiAXXCUznYyD9J6AhDesSvGCRCo3OStKaxr7jM=
   </X509Certificate>
  </X509Data>
 </KeyInfo>
</Identity>

Can you imagine: CardSpace just throws away this certificate and never uses it!

What is this certificate anyway? Some clever people came up with the idea that EndpointReferences need more security and should be protected by Identity. One way to provide endpoint identity information is to specify which certificate will be used by the (security token issuer) endpoint. This for the theory; in practice CardSpace does not use this information.

Why? Well, when the certificate is valid at the time the information card is issued but invalid after some time then the issuer would have to re-issue all cards that contain an EndpointReference with that certificate attached...
Microsoft thinks, I guess, that in general people - even professionals - are to stupid to handle the crypto-thingy correcly.
I don't know. I think that we should expect an Identity Provider to know its business and part of that business is to handle the certificates/keypairs etc so that the Identity Metasystems handles a renewed certificate without hickups.

An alternative to specifing a certificate is to specify an RsaPublicKey. This has no validity dates attached to it so it can not become invalid. If the STS specifies the public key then it can change certificates or part of the information in the certificate as long as the keypair stays the same.
This advantage of keypairs in contrast to certificates is an disadvantage too. Should the private key of the keypair be compromised then all information cards have to be re-issued (Super-GAU). Well, this falls in the category "This should never happen". We should expect to see this not too often.
Enough gossip for now. Time to call it a day.

Enjoy.

Identity.xsd reloaded

I was wondering why the identity xml schema was not updated after the release of ISIP 1.5...

Here is my (unautorized) edit. Any xml that validates against the old schema should by valid against this new schema (but not the other way around). Well, I changed the namespace from http://schemas.xmlsoap.org/ws/2005/05/identity/ to http://schemas.xmlsoap.org/ws/2008/08/identity/:


<?xml version="1.0" encoding="utf-8"?>
<!-- 
Copyright © 2006-2007 Microsoft Corporation, Inc. All rights reserved. 
Edited for Identity Selector Interoperability Profile V1.5 by Axel Nennker. Some rights reversed. [sic!]
-->

<xs:schema targetNamespace="http://schemas.xmlsoap.org/ws/2008/08/identity"
    xmlns:tns="http://schemas.xmlsoap.org/ws/2008/08/identity" 
    xmlns:wsa="http://www.w3.org/2005/08/addressing" 
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
    xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
    
    elementFormDefault="qualified" blockDefault="#all" 

    version="0.1" >

  <xs:import 
      namespace="http://www.w3.org/2001/04/xmlenc#" 
      schemaLocation="http://www.w3.org/TR/xmlenc-core/xenc-schema.xsd"/>
  <xs:import 
      namespace="http://www.w3.org/2005/08/addressing" 
      schemaLocation="http://www.w3.org/2006/03/addressing/ws-addr.xsd"/>
  <xs:import 
      namespace="http://schemas.xmlsoap.org/ws/2004/09/policy" 
      schemaLocation="http://schemas.xmlsoap.org/ws/2004/09/policy/ws-policy.xsd" /> 
  <xs:import 
      namespace="http://schemas.xmlsoap.org/ws/2005/02/trust" 
      schemaLocation="http://schemas.xmlsoap.org/ws/2005/02/trust/ws-trust.xsd" />
  <xs:import
      namespace="http://www.w3.org/2000/09/xmldsig#"
      schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
  <xs:import
      namespace="http://www.w3.org/XML/1998/namespace"
      schemaLocation="http://www.w3.org/2001/xml.xsd"/>
  
  <!-- Standard claim types defined by the InformationCard model -->

  <xs:simpleType name="StringMaxLength255MinLength1">
    <xs:restriction base="xs:string">
      <xs:maxLength value="255"/>
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="StringMaxLength64MinLength1">
    <xs:restriction base="xs:string">
      <xs:maxLength value="64"/>
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="StringMaxLength684">
    <xs:restriction base="xs:string">
      <xs:maxLength value="684"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="Base64BinaryMaxSize1MB">
    <xs:restriction base="xs:base64Binary">
      <xs:maxLength value="1048576"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="Base64BinaryMaxSize16K">
    <xs:restriction base="xs:base64Binary">
      <xs:maxLength value="16384"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="Base64BinaryMaxSize1K">
    <xs:restriction base="xs:base64Binary">
      <xs:maxLength value="1024"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="PositiveUnsignedInt">
    <xs:restriction base="xs:unsignedInt">
      <xs:minInclusive value="1"/>
    </xs:restriction>
  </xs:simpleType>
  
  <xs:complexType name="AttributedEmptyElement">
    <xs:anyAttribute namespace="##other" processContents="lax" />
  </xs:complexType>

  <xs:element name="DisplayCredentialHint" type="tns:StringMaxLength64MinLength1" />
  <xs:element name="Username" type="tns:StringMaxLength255MinLength1" />

  <xs:element name="PrivatePersonalIdentifier" type="tns:Base64BinaryMaxSize1K" />
  <xs:element name="IsSelfIssued" type="xs:boolean" />
  <xs:element name="MasterKey" type="tns:Base64BinaryMaxSize1K" />
  <xs:element name="PinDigest" type="tns:Base64BinaryMaxSize1K" />

  <xs:element name="HashSalt" type="tns:Base64BinaryMaxSize1K" />
  <xs:element name="IssuerId" type="tns:Base64BinaryMaxSize16K" />
  <xs:element name="BackgroundColor" type="xs:int" />
  <xs:element name="CardName" type="tns:StringMaxLength255MinLength1" />

  <xs:element name="Issuer" type="xs:anyURI" />
  <xs:element name="IssuerName" type="tns:StringMaxLength64MinLength1" />
  <xs:element name="TimeIssued" type="xs:dateTime" />
  <xs:element name="TimeExpires" type="xs:dateTime" />

  <xs:element name="TimeLastUpdated" type="xs:dateTime" />
  <xs:element name="StoreSalt" type="tns:Base64BinaryMaxSize1K" />
  <xs:element name="EntryName" type="tns:StringMaxLength64MinLength1" />
  <xs:element name="EntryValue" type="tns:StringMaxLength684" />

  <xs:simpleType name="LogoImageType">
    <xs:restriction base="xs:token">
      <xs:enumeration value="image/jpeg"/>
      <xs:enumeration value="image/gif"/>
      <xs:enumeration value="image/bmp" />
      <xs:enumeration value="image/png" />
      <xs:enumeration value="image/tiff" />
    </xs:restriction>
  </xs:simpleType>
  
  <xs:complexType name="BaseClaimType" abstract="true">
    <xs:attribute name="Uri" type="xs:anyURI" use="required" />
  </xs:complexType>

  <xs:element name="ClaimType" type="tns:ClaimType" />
  <xs:complexType name="ClaimType">
    <xs:complexContent>
      <xs:extension base="tns:BaseClaimType">
        <xs:attribute name="Optional" type="xs:boolean" />
        <xs:anyAttribute namespace="##other" processContents="lax" />
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="SupportedClaimType" type="tns:SupportedClaimType" />
  <xs:complexType name="SupportedClaimType">
     <xs:complexContent>
       <xs:extension base="tns:BaseClaimType">
         <xs:sequence>
          <xs:element name="DisplayTag" type="tns:StringMaxLength255MinLength1" minOccurs="0" />
          <xs:element name="Description" type="tns:StringMaxLength255MinLength1" minOccurs="0" />
        </xs:sequence>
        <xs:anyAttribute namespace="##other" processContents="lax" />

      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="InformationCardReference" type="tns:InformationCardReferenceType" />
  <xs:complexType name="InformationCardReferenceType">
    <xs:sequence>
      <xs:element name="CardId" type="xs:anyURI" />
      <xs:element name="CardVersion" type="tns:PositiveUnsignedInt"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="CardImage" type="tns:CardImageType" />

  <xs:complexType name="CardImageType">
    <xs:simpleContent>
      <xs:extension base="tns:Base64BinaryMaxSize1MB">
        <xs:attribute name="MimeType" type="tns:LogoImageType" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:element name="UsernamePasswordCredential" type="tns:UsernamePasswordCredentialType" />
  <xs:complexType name="UsernamePasswordCredentialType">
    <xs:sequence>
      <xs:element ref="tns:Username" minOccurs="0"/>

    </xs:sequence>
  </xs:complexType>

  <xs:element name="KerberosV5Credential" type="tns:AttributedEmptyElement" />

  <xs:element name="X509V3Credential" type="tns:X509V3CredentialType" />
  <xs:complexType name="X509V3CredentialType">

    <xs:sequence>
      <xs:element ref="ds:X509Data"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="SelfIssuedCredential" type="tns:SelfIssuedCredentialType" />
  <xs:complexType name="SelfIssuedCredentialType">

    <xs:sequence>
      <xs:element ref="tns:PrivatePersonalIdentifier"/>
    </xs:sequence>
  </xs:complexType>
  
  <xs:element name="UserCredential" type="tns:UserCredentialType" />
  <xs:complexType name="UserCredentialType">

    <xs:sequence>
      <xs:element ref="tns:DisplayCredentialHint" minOccurs="0" />
      <xs:choice>
        <xs:element ref="tns:UsernamePasswordCredential" />
        <xs:element ref="tns:KerberosV5Credential" />

        <xs:element ref="tns:X509V3Credential" />
        <xs:element ref="tns:SelfIssuedCredential" />
        <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax" />
      </xs:choice>

    </xs:sequence>
  </xs:complexType>

  <xs:element name="IssuerInformationEntry" type="tns:IssuerInformationEntryType" />
  <xs:complexType name="IssuerInformationEntryType">
    <xs:sequence>
      <xs:element ref="tns:EntryName" />
      <xs:element ref="tns:EntryValue" />
    </xs:sequence>
  </xs:complexType>

  <xs:element name="IssuerInformation" type="tns:IssuerInformationType" />
  <xs:complexType name="IssuerInformationType">

    <xs:sequence>
      <xs:element ref="tns:IssuerInformationEntry" minOccures="1" />
    </xs:sequence>
  </xs:complexType>


  <xs:element name="TokenService" type="tns:TokenServiceType" />

  <xs:complexType name="TokenServiceType">
    <xs:sequence>
      <xs:element ref="wsa:EndpointReference" />
      <xs:element ref="tns:UserCredential"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax" />

  </xs:complexType>

  <xs:element name="TokenServiceList" type="tns:TokenServiceListType" />
  <xs:complexType name="TokenServiceListType">
    <xs:sequence>
      <xs:element ref="tns:TokenService" maxOccurs="128"/>

    </xs:sequence>
  </xs:complexType>

  <xs:element name="SupportedTokenTypeList" type="tns:SupportedTokenTypeListType" />
  <xs:complexType name="SupportedTokenTypeListType">
    <xs:sequence>
      <xs:element ref="wst:TokenType" maxOccurs="32"/>

    </xs:sequence>
  </xs:complexType>

  <xs:element name="SupportedClaimTypeList" type="tns:SupportedClaimTypeListType" />
  <xs:complexType name="SupportedClaimTypeListType">
    <xs:sequence>
      <xs:element ref="tns:SupportedClaimType" maxOccurs="128"/>

    </xs:sequence>
  </xs:complexType>

  <xs:element name="RequireAppliesTo" type="tns:RequireAppliesToType" />
  <xs:complexType name="RequireAppliesToType">
    <xs:attribute name="Optional" type="xs:boolean" />

  </xs:complexType>
  
  <xs:element name="RequestDisplayToken">
    <xs:complexType>
      <xs:attribute ref="xml:lang" use="optional" />
      <xs:anyAttribute namespace="##other" processContents="lax" />

    </xs:complexType>
  </xs:element>
  
  <xs:element name="DisplayClaim" type="tns:DisplayClaimType" />
  <xs:complexType name="DisplayClaimType">
    <xs:complexContent>
      <xs:extension base="tns:SupportedClaimType">

        <xs:sequence>
          <xs:element name="DisplayValue" type="tns:StringMaxLength255MinLength1" minOccurs="0" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

   <xs:simpleType name="DisplayTokenTextContentType">
     <xs:restriction base="xs:token">
      <xs:enumeration value="text/plain" />
    </xs:restriction>
  </xs:simpleType>

  <xs:element name="DisplayTokenText" type="tns:DisplayTokenTextType" />

  <xs:complexType name="DisplayTokenTextType">
    <xs:simpleContent>
      <xs:extension base="tns:StringMaxLength255MinLength1">
        <xs:attribute name="MimeType" type="tns:DisplayTokenTextContentType" use="required" />
        <xs:anyAttribute namespace="##other" processContents="lax" />

      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:element name="DisplayToken" type="tns:DisplayTokenType" />
  <xs:complexType name="DisplayTokenType">
    <xs:choice>

      <xs:element ref="tns:DisplayClaim" maxOccurs="unbounded" />
      <xs:element ref="tns:DisplayTokenText" />
    </xs:choice>
    <xs:anyAttribute namespace="##other" processContents="lax" />
  </xs:complexType>

  <xs:element name="RequestedDisplayToken" type="tns:RequestedDisplayTokenType" />
  <xs:complexType name="RequestedDisplayTokenType">
    <xs:sequence>
      <xs:element ref="tns:DisplayToken" />
    </xs:sequence>

    <xs:anyAttribute namespace="##other" processContents="lax" />
  </xs:complexType>

  <xs:element name="RequireStrongRecipientIdentity" type="tns:PolicyAssertionType" />
  <xs:element name="RequireFederatedIdentityProvisioning" type="tns:PolicyAssertionType" />

  <xs:complexType name="PolicyAssertionType">
    <xs:sequence>
      <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax" />
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax" />

  </xs:complexType>
  
  <xs:element name="PrivacyNotice" type="tns:PrivacyNoticeLocationType" />
  <xs:complexType name="PrivacyNoticeLocationType">
    <xs:simpleContent>
      <xs:extension base="xs:anyURI">
        <xs:attribute name="Version" use="optional" type="tns:PositiveUnsignedInt"/>

        <xs:anyAttribute namespace="##any" processContents="lax" />
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:element name="ClaimValue" type="tns:ClaimValueType" />

  <xs:complexType name="ClaimValueType">
    <xs:complexContent>
      <xs:extension base="tns:BaseClaimType">
        <xs:sequence>
          <xs:element name="Value" type="tns:StringMaxLength684" />
        </xs:sequence>

      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="ClaimValueList" type="tns:ClaimValueListType" />
  <xs:complexType name="ClaimValueListType">
    <xs:sequence>

      <xs:element ref="tns:ClaimValue" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="InformationCard" type="tns:InformationCardType" />
  <xs:complexType name="InformationCardType">

    <xs:sequence>
      <xs:element ref="tns:InformationCardReference" />
      <xs:element ref="tns:CardName" minOccurs="0" />
      <xs:element ref="tns:CardImage" minOccurs="0" />
      <xs:element ref="tns:Issuer" />

      <xs:element ref="tns:TimeIssued" />
      <xs:element ref="tns:TimeExpires" minOccurs="0" />
      <xs:element ref="tns:TokenServiceList" minOccurs="0"/>
      <xs:element ref="tns:SupportedTokenTypeList" />

      <xs:element ref="tns:SupportedClaimTypeList" />
      <xs:element ref="tns:RequireAppliesTo" minOccurs="0" />
      <xs:element ref="tns:PrivacyNotice" minOccurs="0" />
      <xs:element ref="tns:RequireStrongRecipientIdentity" minOccurs="0" />
      <xs:element ref="tns:IssuerInformation" minOccurs="0" maxOccurs="unbounded" />
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute ref="xml:lang" use="required"/>

  </xs:complexType>

  <xs:element name="InformationCardMetaData" type="tns:InformationCardMetaDataType" />
  <xs:complexType name="InformationCardMetaDataType">
    <xs:complexContent>
      <xs:extension base="tns:InformationCardType">
        <xs:sequence>

          <xs:element ref="tns:IsSelfIssued" />
          <xs:element ref="tns:PinDigest" minOccurs="0"/>
          <xs:element ref="tns:HashSalt" />
          <xs:element ref="tns:TimeLastUpdated" />
          <xs:element ref="tns:IssuerId" />

          <xs:element ref="tns:IssuerName" />
          <xs:element ref="tns:BackgroundColor" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="InformationCardPrivateData" type="tns:InformationCardPrivateDataType" />
  <xs:complexType name="InformationCardPrivateDataType">
    <xs:sequence>
      <xs:element ref="tns:MasterKey" />
      <xs:element ref="tns:ClaimValueList" minOccurs="0" />

    </xs:sequence>
  </xs:complexType>

  <xs:element name="RoamingInformationCard" type="tns:RoamingInformationCardType" />
  <xs:complexType name="RoamingInformationCardType">
    <xs:sequence>
      <xs:element ref="tns:InformationCardMetaData" />

      <xs:element ref="tns:InformationCardPrivateData" minOccurs="0" />
    </xs:sequence>
  </xs:complexType>

  <xs:element name="RoamingStore" type="tns:RoamingStoreType" />
  <xs:complexType name="RoamingStoreType">

    <xs:sequence>
      <xs:element ref="tns:RoamingInformationCard" minOccurs="1" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="EncryptedStore" type="tns:EncryptedStoreType" />

  <xs:complexType name="EncryptedStoreType">
    <xs:sequence>
      <xs:element ref="tns:StoreSalt" />
      <xs:element ref="enc:EncryptedData" />
    </xs:sequence>
  </xs:complexType>

  
</xs:schema>