Cardspace Support for Firefox

During the last week I released new versions of the Mozilla Firefox addon that adds Cardspace support to the browser.

One feature that was reenabled was the ability to get the "value" of the object element using javascript. The value is the security token and thus requesting the value starts the selector. This "feature" was lost in the past and was quite easy to reactivate.

Another change that envolved code changes in many places was the elemination of global variables. Which is a good thing. All global variables were moved into a new namespace org.openinfocard.cs4ff. I hope that this change gets this addon out of the sandbox and it will become an addon that can be installed without the "let me install this" checkbox.

To bad that the Information Card addons are not compatible with each other. You have to make your choice whether you install DigitalMe, Openinfocard, Azigo's selector or Cardspace4Firefox. Or other addons based on the same code base.
Which on the other hand is no problem in the real world. Users will pick their selector and install just one.

Avoco RealPay etc

In case you have not done so please have a look at Avoco's Information Card work.

One of their demo sites is a site called RealPay. Here you see the current openinfocard selector at work:





But the above is only the "normal" Information Card scenario.
Much more interesting are their "cloud selector" and their Cardspace based document signing product. The latter can sign Microsoft Office documents and PDFs and if you try to open that document you have to present a valid security token based on an Information Card which might be restricting your access even to your current location. Nice.
Read more here.

Information Card Simple Profile

Normally, before the selector requests a security token from the IdP's tokenservice endpoint it asks the metadata endpoint of the IdP and retrieves that metadata which tells it whether transport-security or symmetric-binding and other things are to be used in the token request.

I suggest that we define a simple-profile that basically skips the metadata retrievel step and replace it with default data.

The IdP that wants the simple-profile to be used just issues Information Cards that do not contain the metadata endpoint information.

Instead of:
 <ic:TokenService>
    <wsa:EndpointReference>
      <wsa:Address>https://contoso.com/sts/pwd</wsa:Address>
      <wsa:Metadata>
        <wsx:Metadata>
          <wsx:MetadataSection
              Dialect="https://schemas.xmlsoap.org/ws/2004/09/mex">
            <wsx:MetadataReference>
              <wsa:Address>https://contoso.com/sts/pwd/mex</wsa:Address>
            </wsx:MetadataReference>
          </wsx:MetadataSection>
        </wsx:Metadata>
      </wsa:Metadata>
    </wsa:EndpointReference>
    <ic:UserCredential>
      <ic:UsernamePasswordCredential>
        <ic:Username>Zoe</ic:Username>
      </ic:UsernamePasswordCredential>
    </ic:UserCredential>
  </ic:TokenService>
</ic:TokenServiceList>

the Information Card would contain just:
 <ic:TokenService>
    <wsa:EndpointReference>
      <wsa:Address>https://contoso.com/sts/pwd</wsa:Address>
    </wsa:EndpointReference>
    <ic:UserCredential>
      <ic:UsernamePasswordCredential>
        <ic:Username>Zoe</ic:Username>
      </ic:UsernamePasswordCredential>
    </ic:UserCredential>
  </ic:TokenService>
</ic:TokenServiceList>

What are the default values of the metadata that the selector assumes?:

• Transport Security must be used; the IdP tokenservice uses SSL/TLS.
• We might assume that the Information Card signing certificate is the same as the security tokenservice certificate; IFF the issuer does not use WS-AddressingAndIdentity to specify the STS certificate...

Maybe there are other assumptions that I just can not remember now? What are the security implications?
Please help to make the Identity Metasystem as simple as possible (but not simpler).

Your search - cardspace site:microsoft.de - did not match any documents.

http://www.google.de/search?q=cardspace+site%3Amicrosoft.de yields:

Not good! It seems that the German Microsoft site is not searched by Google. Strange.
Ahh. Searching for German language content on microsoft.com yields results...
Still...

Searching for Cardspace at search.microsoft.com results in an interesting suggestion: "Meinten Sie vielleicht: cards pace" (did you mean 'cards pace'). It seems that search.microsoft.com does not know Microsoft products.

Waiting for CardSpace Geneva

I wanted this video to loop forever but could not find how this is possible.
Maybe Microsoft should open source CardSpace Geneva; then we could help to bring it into the world.

please think of the kittens

While searching what others write about Information Cards I found this older presentation and want to share especially one slide with you:
If you made OpenID phishing resistant then you have Microsoft CardSpace Geneva?! We need a secure (enough) UI for login and attribute sharing through OpenID, Information Cards and even username/password. I think that cards are a metaphore that users understand and what happens underneath the UI should not really concern the user. I don't want to remember an OpenID or a password, I want to choose a card and what happens under the hood... who cares?! Well, the server vendors care but not the user.
Please join the discussion at the Information Card Foundation!

Car Re-Registration with Information Cards and German eID by Fraunhofer Fokus

Fraunhofer Fokus demoed a cool scenario where a user re-registers his car using the new German eId and Microsoft CarsSpaceCardspace. What I exspecially liked that the slides show Firefox and the openinfocard selector installed.



The following is the text from the slide:
Re-registration of a car can prove a real headache. But the Fraunhofer Institute for Open Communication Systems FOKUS in Berlin has joined forces with the Bundesdruckerei to develop the prototype of an electronic automobile re-registration procedure that can be conveniently operated using the home computer.
To use this simple procedure, however, the citizen first requires a safe means of identity in the digital world. He or she requires an electronic identity or ‘e-identity’ which needs to be created, administered and decommissioned.
Across its life cycle the digital identity can be used for a wide variety of different transactions and activities – but always with the aim of proving the identity of the real individual in the virtual world. Users must be able to navigate in the digital world; they must reveal certain information about themselves – but not too much and certainly not to everybody. At the same time increasingly pervasive networking means that previously separate islands of identity have now to interact and cooperate.
In the ‘Re-registration of an Vehicle’ scenario the car owner can use an electronic ID card as a means of identification of the type that will come into use in Germany in 2010. Using this card she logs onto a user-centric service – the scenario uses Windows’ CardSpace – which issues her with a ‘digital card’ or Information Card which she can use via an identity provider to safely authenticate herself on an vehicle portal. Using an electronic vehicle registration certificate – which could also become widely available in future – the car registration office can then read off the key data about the car via the internet and store the data that has been changed.
The citizen then transfers the revised data to a future digital license tag.
Please contact Jens Fromm from Fraunhofer Fokus for more information.

Backward Compatibility. Java, Mozilla, Sun, IBM, Microsoft

About a week ago there were press articles about SAP paying SUN Microsystem to support SAP customers with stoneage java 1.4 users/systems.

Unfortunately there is nobody who wants to own and support the stoneage OJI project that puts java support into Firefox. The new way to support java is provided through the NSAPI plugin interface and the new thing is called "plugin2". Unfortunately (again) SUN forgot - or never knew - that Firefox extensions have - if they want - all the rights of the Firefox user. SUN implemented plugin2 having java applets in mind. Firefox extension that use java were forgotten.

But Sun is very helpful to ease the pain and supports me - thanks Kenneth - in rewriting the java classloading stuff from OJI to plugin2. But (again) you need java 6 update 12 or newer for this to work. This version of java has a patch for plugin2 that gives Firefox extensions the necessary priveledges.

So currently there are two options for openinfocard users: either disable plugin2 as I discribed in previous posts or install java6u12ea.
When Mozilla stops support for OJI then there is only the option to install a current version of java. I guess that Firefox 3.2 will not have OJI inside.

This reminds of an email thread/t on the higgins-dev mailing list. Where most developers wished for java 5 in higgins but IBM's shogun ordered his men to commit harakiri should they become traitors to java 1.4. Well, I am exaggerating...

I guess that IBM does not want to pay SU... - Hm, IBM has its own java - IBM to migrate customers stoneage IBM systems to a better world?!

Other memories bubble up: Did you remember the news that Microsoft CardSpace was downgraded to run on FAT file systems?

Well, well, well. I am happy that openinfocard is provided AS-IS.
I will do my best to support all versions of Firefox on all platforms, but my resources are limited. So we all should be happy if we can always work with the latest and greatest software. Happy downloading. Enjoy.

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.

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.

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 Identity	The 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 Dive	In 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 Hood	Windows 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?

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.

Information Card Subtleties

From ISIP 1.5:

<ic:InformationCardMetaData>
[Information Card]
<ic:IsSelfIssued> xs:boolean </ic:IsSelfIssued>
<ic:PinDigest> xs:base64Binary </ic:PinDigest> ?
<ic:HashSalt> xs:base64Binary </ic:HashSalt>
<ic:TimeLastUpdated> xs:dateTime </ic:TimeLastUpdated>
<ic:IssuerId> xs:base64Binary </ic:IssuerId>
<ic:IssuerName> xs:string </ic:IssuerName>
<ic:BackgroundColor> xs:int </ic:BackgroundColor>
</ic:InformationCardMetaData>

.../ic:InformationCardMetaData/ic:IsSelfIssued This required element indicates if the card is self-issued (“true”) or not (“false”).

.../ic:InformationCardMetaData/ic:IssuerId This required element contains an identifier for the Identity Provider with which a self-issued credential descriptor in a card issued by that Identity Provider can be resolved to the correct self-issued card. The element content may be empty.

The ic:IssuerId value used for a card when representing it in the Information Cards Transfer Format SHOULD be computed as a function of the ds:KeyInfo field of the envelope digitally signed by the Identity Provider. Specifically:

• Compute IP Identifier in the same manner as RP Identifier in Section 8.6.1, except that the certificate from ds:KeyInfo is used, rather than the Relying Party‟s.

Use the IP Identifier as the ic:IssuerId value. The ic:IssuerId value SHOULD be the empty string for self-issued cards.

.../ic:InformationCardMetaData/ic:IssuerName This required element contains a friendly name of the card issuer.

The ic:IssuerName value used for a card when representing it in the Information Cards Transfer Format SHOULD be computed as a function of the ds:KeyInfo field of the envelope digitally signed by the Identity Provider. Specifically, if the certificate from ds:KeyInfo is an extended validation (EV) certificate [EV Cert], then set ic:IssuerName to the Organization Name (O) field value from the certificate, otherwise set ic:IssuerName to the Common Name (CN) field value from the certificate.

ISIP 1.5 does not state what the value for IssuerName is in the case when IsSelfIssued == true. I think it SHOULD be empty too like IssuerId when IsSelfIssued == true.
[update: Just saw that the XML schema defines IssuerName to be of the type "StringMaxLength64MinLength1". It can not be empty. I suggest that we do away with this "required element should be empty if..."-stuff and define IssuerId and IssuerName to be optional. Or better: We should move IssuerId into the definition "SelfIssuedCredentialType" as it is needed only for this authentication type.
For IssuerName I suggest that we move this element into the Information Card type "InformationCardType" and define it to be not-there for self-issued cards and non-empty for managed cards. The issuer should have the right to choose its name. Deriving it from the cert imposes unneeded restrictions on the issuer. The card is signed and after I verified/validated and accepted the card from that issuer I should accept its choosing for IssuerName.]

IssuerId and IssuerName are defined in the section of ISIP 1.5 titled: "7. Information Cards Transfer Format" and subsection "7.1. Pre-Encryption Transfer Format"; that is: They are needed/computed when a card is exported? This does not make sense. I assume that they are computed when the .crd file is imported.
The XML in the .crd file is signed and the ds:KeyInfo from the signature contains the certificate that is used to sign the XML.
What if the ds:KeyInfo from the signature contains no ds:X509Certificate?

Question: Is there a connection between ic:IssuerId and ic:IssuerName from the ic:InformationCardMetaData and ic:Issuer from ic:InformationCard?
Answer: No. The ic:Issuer from ic:Information card is an URI and is the logical name of the issuer. Potential RPs and Issuers must agree on this logical name because it is used to determine a matching card when the RPs asks for a specific issuer in the HTML object tag.

If the RP limits the accepted tokens to those issued by issuer="urn:flabergasted" then there is no intuitive way to find an STS that issues these tokens. Should the issuer from the HTML object tag be the same as the ic:IssuerName? Probably.

So, what is the use of IssuerId and IssuerName? IssuerName is used to present it to the user when the managed card is displayed to the user. IssuerId is used to find the self-issued card when the managed card is backed by a self-issued card. If the UserCredential is has no ic:SelfIssuedCredential child then IssuerId is not needed.

-----
What if the issuer uses another certificate to sign the issued managed Information Card than for its SSL connection? Is this a "legal" scenario?

New York Times on Passwords and Alternatives

There is a new article by Randall Stross in the New York Times titled "Goodbye, Passwords. You Aren’t a Good Defense".

I am thankful for this article and I think that we need more of them. It is targeted at a readership that is no expert in security and privacy; and never will be. It informs its readers that there are problems with passwords and that openid (yet?) isn't the solution either. I think that with Information Cards we are moving in the right direction. True, we are not there yet, but major players by forming the Information Card Foundation have decided to jointly work on a accepted and interoperable solution.

Microsoft is doing the right thing to put their implementation of the card selector, CardSpace, into Windows Vista. And to improve it again and again; and put this major component for Internet security outside the long Windows and .NET update cycles; and to support alternative implementations of the identity selector and the other components of the Identity Metasystem.

One thing that I am missing from the article is the notion of "claims". Information Cards are "information cards" not "login cards" and especially they are no "id cards"; they might be used for authentication and even identification but, I believe, that the major thing to note about Information Cards is that they, by means of a trusted client component - the card/identity selector - enable the secure and privacy friendly exchange of data about the user.

Information Cards will be available on major operating systems and browsers. Many people are working on this and we will be successful.

Carnards Die Hard

A while ago two students, Xuan Chen and Christoph Löhr, from Ruhr University Bochum claimed to have "broken" CardSpace. There were some blog reactions to this claim. The authoritative one of course is from Kim.

Today I browsed through a magazine lying on the desk of a colleague of mine. This magazine with the promising title "IT-Security" repeats the false claim and reports that the students proved that CardSpace has severe security flaws... Well, when you switch off all security mechanism then, yes, there are security flaws (The security researcher in front of the computer).

What can I say?! The existence of this magazine was new to me, but sure they have some readers. The IT-Verlag charges 20€ for this pile of rubbish (Sorry) not very well researched article (page 42).

Interestingly Microsoft is having an ad (the whole second page) in this gazette…

There is still a lot of work for the Information Card Foundation to do.
One of my tasks (privately and not as a member of the ICF) today is to question my colleague about the value of his magazine subscrition...

CardSpace for Firefox new version

I just uploaded a new version 1.0.12 of the Firefox extension that enables CardSpace for Firefox.
This now works for the release version of Firefox 3. Although I know at least one site the drives the javascript kungfu to new heights and that does not work with this version... :-(( Fixed this!

Have fun; and happy testing. Please report issues!

Doppelgänger

Today I updated the xmldap relyingparty to contain two HTML objects of type "application/x-informationcard". To keep things simple I just have put two forms on the website each containing one object. The only difference between the two is that on requires a self-issued card while the other does not restrict the issuer.

The id selectors seem to handle this well. I tested it with the openinfocard id selector and with CardSpace.

What is this good for?! Well, one object could request a card from the issuer "Mastercard" while the other requests a card from the issuer "Visa". Or one could request an issuerpolicy while the other does not...

Interestingly CardSpace fails the test on Pamela's test page for the OSIS interop test. It seems that CardSpace does not like the missing "requiredclaims" parameter...
The openinfocard id selector has its flaws too but they don't stop this test from "working" or do they?

Stealing the Security Token

The Ruhr Uni Bochum claims that they can steal the security token in a CardSpace scenario.... The experts from the German computer magazine c't could not verify the attack...
After reading the paper that describes the attack I must say that I find it very unrealistic.

The attack is described for managed cards. The browser is tricked to load malicious code and then the real RP's code is loaded and presented to the user. The malicious code then loads the root certificate for the malicious RP's SSL certificate and asks the user to install it into the trusted store. This is the biggest assumption in the scenario. Next the user clicks the purple CardSpace icon.

Case 1) Auditing Mode
Assume that CardSpace is tricked to request a token for the malicious RP. When this is the first time CardSpace sees this RP (which is likely) then there might be little CardSpace can do to help the user to recognize the malicious site (because of the installed root certificate). When this is not the first time then CardSpace will warn the user who will probably terminate the transaction.
But who installs a root cert into a trusted store might continue the transaction even when CardSpace raise all flags and blinks all warning lights.

First: The IdP might reject to issue a token to an RP with which it does not have a contract or is outside the (enterprise) circle of trust. Then this attack does not work.
Second: When the IdP issues a token to the malicious RP then that RP can decrypt the token and read the (private) claims. Then it encrypts the assertion for the real RP. The malicious code in the browser (loaded from the malicious server) receives the newly encrypted token and presents it to the form for it to be submitted. The assumption that the malicious code can now reuse the security token to whatever purpose it likes at the RP is not true because the auditing mode restrict its use to the malicious RP.

Case 2) Non-Auditing Mode
Assume the same prerequisites as in case 1. The user is super stupid and the token is stolen and not restricted to the malicious RP. So whenever the real RP expects a security token the malicious code in the browser can provide it.

Do I have to say that an attackers code running inside my browser is probably deadly anyway? Even when the token is not stolen the likelihood that the claims will be a visible part of the "next" page is high, so they can be stolen this way too.

Can't wait to hear what Microsoft writes about this. I had a long busy day and will rethink the whole thing tomorrow.

openid is toast

Mike (one of those who need no sleep) blogged about Fun Communication's openid idtheft site and I encourage you to read Mike's post and try your personal idtheft immediately.

Back here?! Well, you knew all this already, didn't you?
But seeing it in action is another thing, I guess.

So where does this lead us? Remember the "openid dogfight" from September 2007? I too think that we need a spectrum of solutions. I agree that openid is for when an RP has "trivial" security requirements, but I think that trivial is not easy to define. At first your openid might be good enough for trivial things but its value grows with time. The more you use your openid the more valuable it becomes and then the risk you take by using the openid protocol becomes too great to accept. So let us all improve openid through e.g. PAPE. But why? To end up with another secure and inconvenient system? Thanks, no.

• back channels are bad (privacy, user consent). (SAML artefact)
• browser redirect protocols are bad (phishing). (openid protocol, SAML HTTP redirect binding)

Are CardSpace, Higgins' id selector, DigitalMe and openinfocard the solution? Not yet.
I think that the most important things that the Microsoft's vision of the Identity Metasystem until now has brought us are:

• thinking in claims instead of thinking of "login"
• identified the need for a unified user experience when PII is involved
• a client component to achieve the former two

Paul writes that his sxipper prevented the phish. This is a client component like CardSpace and the other id selectors.
We could integrate openid into the id selector and call it "identity agent" or whatever makes this idea stick. But then... Why use openid at all? This is so close to the origin of the security axis that we would need logarithmic scaling to make it visible.

Let us build this identity agent. Let us integrate openid and passwords into the client, but only as a migration path to a convenient and secure alternative.
Down with browser forms for claims/attributes. The browser is your friend.