-==============================-
FOR IMMEDIATE RELEASE

April 7, 2008

MEDIA ALERT
Showcasing How Users Can Control their Identity Online, Industry’s Largest Identity Interoperability Demonstration Scheduled for RSA 2008
Fifty-seven member open source identity group to test and demonstrate interoperability between user-centric identity protocols and providers

SAN FRANCISCO (RSA Conference 2008) – April 7, 2008 – Open Source Identity Systems (OSIS) will conduct the largest user-centric identity interoperability test and demonstration at the 2008 RSA Conference, April 7-11 at the Moscone Center in San Francisco. The 33 member organizations and 24 projects of OSIS will showcase network interoperability between identity providers, card selectors, browsers and Web sites, demonstrating practical uses for user-centric identity technology, including how users can "click-in" to Web sites via self-issued and managed Information Cards and OpenIDs. The user-centric identity model gives consumers greater control and security over their identity information, allowing them to determine how sensitive identity information should be shared at each visited Web site.

During the demonstration, OSIS members will illustrate interoperability between Information Card and OpenID software, the technologies behind user-centric identity.Features being demonstrated include:

* Enabling people to control what identity information is disclosed about them
* Portability of digital identities across software and platforms
* Management and use of Information Cards and OpenIDs
* Information Cards used with OpenIDs to enable phishing-resistant sign-in to Web sites

WHO:OSIS, a working group of Identity Commons (please see below for a list of companies and projects). Members of the group are committed to a goal of Internet identity interoperability across projects, protocols, companies and platforms.

WHAT:OSIS User-Centric Identity Interoperability Demonstration at RSA 2008

WHERE: RSA Conference, Moscone Center South, San Francisco, Mezzanine Level, Purple Room 220

WHEN:Tuesday, April 8 and Wednesday, April 9; public working sessions 11 am to 4 pm, demonstrations 4 pm to 6 pm
About OSIS

Open Source Identity Systems, a working group of Identity Commons, brings together many identity-related open-source and commercial projects, and synchronizes and harmonizes the construction of an interoperable identity layer for the Internet from open-source parts and software that interoperates with them. For more information on OSIS, visit http://wiki.idcommons.net/index.php/OsisCharter.
OSIS participating companies:

* AOL
* ATE Software
* CA
* Cordance
* Fraunhofer FOKUS
* FuGen Solutions
* Fun Communications
* Google
* IBM
* JanRain
* LinkSafe
* Microsoft
* NetMesh
* Novell
* Nulli Secundus
* ooTao
* Oracle
* Orange
* Parity
* Ping Identity
* Plaxo
* Siemens
* SixApart
* Sun Microsystems
* Sxip Identity
* Thinktecture
* ThoughtWorks
* TrustBearer Labs
* VeriSign
* Vidoop
* WSO2
* Yahoo!
* Zend

Projects and Organizations:

* Bandit Project
* Codeplex
* DiSO Project
* Dominck Baier
* Drupal
* Francis Shanahan
* Higgins Project
* I-names
* Identity Commons
* Information Cards
* LID
* OpenID
* OpenInfocard
* OpenSSO
* Open XRI
* Pamela Project
* Rob Richards
* Sharp STS
* SignOn.com
* SourceID
* Shibboleth
* Verisign Personal Identity Provider
* Xmldap
* Yadis

All company/project names and service marks may be trademarks or registered trademarks of their respective companies/organizations.
OSIS Participants Contact Information:

http://osis.idcommons.net/wiki/Category:Participant
Media Contact:

Charlotte Betterley

Novell

(781) 464-8253

cbetterley@novell.com
-==============================-

What’s going on? The internet has a crappy way of managing your personal information. We’re trying to fix that.

Why should I care? Right now you’re at quite a high risk of having your identity stolen, losing control of your personal information, of being phished or losing track of what personal information is stored where. See my previous post on Identity Fragmentation [LINK].

So what are you talking about now? RSA is happening NEXT WEEK! (7-11th April) [LINK]

What’s RSA? Only the largest conference focused on information security in the world. It starts in San Francisco and is replicated around the world.

Is Shanahan going to be there? Well no, but my code will be. A while back I created a Cardspace Identity Provider and Relying Party test harness [LINK]. That code has been participating in the OSIS Interop 2008.

What’s OSIS Interop? It’s a grass-roots effort to prove out the interoperability of various Identity solutions.

We’ve been testing the interoperability (how things work together) of all these solutions since January. You can checkout the results of the testing here [LINK].

Who’s participating?  Easy, just checkout this diagram (yes that’s my logo underneath Bandit!): Click for a LARGER image.

Checkout what Mike Jones, Pamela Dingle and Kim Cameron have to say on the topic.

So get yourself to RSA and checkout the OSIS Interop room. They have BEER!!! [LINK]

The Foreword is by Identity luminary (and friend) Kim Cameron and if I’m keeping it real, rather than describe the book’s contents, I wish he’d shared more thoughts around the problem space, the approach to the solution and the roadmap BEYOND cardspace.  Here’s Kim’s take on the book [LINK].

The book itself is an easy read. Not a tome by an means. Easy to pickup as a reference or to sit with and read chapter by chapter.

It succeeds at describing Identity Federation from a conceptual level as well as from a technical level (as it pertains to Cardspace). It even addresses some of the less obvious issues such as the notion of auditing and non-auditing IdPs.

Be warned, this book focuses on Cardspace fairly exclusively. There isn’t a lot on interoperability here between things like OpenID and Cardspace for example. That’s a topic for another book and could not easily be incorporated without devoting a lot of pages to OpenID.

The technical section is navigated through use cases that tackle things from an end-user experience as well as from the developer angle. This is effective as often it’s hard to understand one without the other. At every point the reasoning behind the solution is presented also. This worked well.

For me personally, I wish they’d spent a little more time on things like GetToken() although using this directly will likely not be of interest to 90% of folks out there.

Unique to books of this type is a section devoted to Practical Considerations. Why one would want to setup an IdP or simply play the role of Identity Consumer for example. In today’s environment the business value of establishing yourself as an IdP is questionable and I was glad to see this point addressed head on.

Vittorio, Garrett and Caleb have done an terrific job of describing and grounding one of the most compelling and abstract problems faced by the internet today. This an excellent book and for many will serve as a one-stop-shop for all your Cardspace questions.

It’s a beautiful thing when the RP and IdP just "work". Checkout the results here [LINK].

For a semi-homegrown solution I’d say that’s not bad. Maybe instead of "trusting" someone with my valuable identity information, I can just be my OWN identity provider?

As mentioned in an earlier post, my Cardspace Relying Party Test Harness[LINK] as well as my Identity Provider [LINK] are in the testing this year. I get a big kick out of seeing the interoperability work between my hacked-together test harness and the other implementations out there.

Results are being gathered in the following matrix and will likely be reviewed at RSA 2008 this year.
[http://osis.idcommons.net/wiki/I3:Cross_Solution_Results]

After some initial testing it seems my RP/IdP works reasonably well as long as it’s based on SAML 1.0 and not too strict on the token elements.

Really looking forward to this one and hoping it will answer some of the more obscure questions I’ve encountered in my Cardspace Explorations.

In related news, my Cardspace STS and Managed Card Test Harness [LINK] is in the mix of RPs and IdPs currently being tested as part of the latest OSIS interop. Many thanks to Mike Jones [LINK] for including me on this. The list of participants is here: [LINK] and it looks like results will be posted on this Wiki page [LINK].

But what if you just want to protect a file. Or an XML resource like an RSS feed?

In this post I’ll propose an extension which would allow Cardspace to be leveraged to protect resources without the need for a UI to be rendered in the browser.

The scenario I’m proposing works like this: Let’s say I have a file, "fs.png" that I want to protect using claims. I host the file somewhere. This is my "claims protected resource".
Now I want to give you a link to the file so you can download it, but only if you have a good token.

Instead of me giving you a link to the file, I give you a link to an XML document that describes the file along with the claims needed to access it. I’ve called this document a "claims protected resource manifest".
It looks like this:

<claimsProtectedResource>
  <tokenDetails>
    <tokenType value="urn:oasis:names:tc:SAML:1.0:assertion=" />
    <requiredClaim>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier</requiredClaim>
    <requiredClaim>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname</requiredClaim>
    <requiredClaim>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname</requiredClaim>
    <optionalClaim>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress</optionalClaim>
     <issuer>http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self</issuer>
  </tokenDetails>
  <targetResource>cprExampleImage.png</targetResource>
  <targetCert>http://www.francisshanahan.com/cardspace/fs.cer</targetCert>
  <claimConsumer>http://www.francisshanahan.com/cardspace/cprConsumer.aspx</claimConsumer>
</claimsProtectedResource>

The XML here consists of a targetResource (the file you’re trying to access) along with details of the token needed to access that file. Very similar to the object tag notation currently in use.

When the web server serves this manifest file, it serves it with a new mime type (application/cpresx-manifest) (I just made this up).

That mime-type is associated with a small shim application that you can download and install here [LINK]. The shim examines the manifest and launches Cardspace to obtain a token. In this case a Self Issued Card token.
Once Cardspace is finished, control returns to the shim which forwards the token along with the identifier of the desired file on to a token consumer service on the server.

The token consumer processes the token and streams down the file you asked for originally.

To test this scenario yourself…

1. first install the shim application available here [LINK]
2. Then access the claims protected resource manifest here [LINK]

You’ll need a self-issued card for this example but the model could be used with managed cards also.

In this example, the claim consumer will grant you access to the resource with any card EXCEPT a card with the first name set to "noaccess".

——— TROUBLE SHOOTING ———
This app is just a POC and has little error handling.

If you run access the manifest link and nothing happens, try saving the manifest to disk and running the application from the command line like this:
C:Program FilesFrancis Shanahan[.com]Claims Protected Resource Shim>CPR_Shim mydoc.cpresx

If you’re behind a proxy, add an app.config file with the proxy details to the same folder as CPR_shim.exe. The contents of the app.config file should look like this:

C:Documents and Settings<USERNAME>Local SettingsTempcprExampleImage.png

If the cprExampleImage.png file is there just double click it. If an "Open With…" dialog pops up, pick an application (like Internet Explorer or Paint) and make sure to click "always do this" checkbox.

After all that you should be in business. Hey, what do you want for a couple of hours work?

——————————————–
This example requires a shim as there’s no such thing as a "claims protected resource manifest" in the current Cardspace spec. I like this pattern as it

1. Doesn’t require a session on the server
2. Supports bookmarking and emailing of links through the CPR manifest notion
3. Extensible to any resource type
4. Easy deployment, hooking cardspace up with a Mime Type seems to make sense
5. Abstracts the actual resources from end users and puts claims right in the middle.

I think that this pattern has its uses and would propose that this pattern (maybe not my implementation) be considered as an enhancement to Cardspace in a future release.

Attribution: Many thanks to Dominick Baier of LeastPrivilige.com[LINK] who supplied the Cardspace abstraction on which the shim code is based. [LINK]

Last night I took a stab at listing out the various entities that know me, regardless of how they know me. The list is overwhelming. It quickly became apparent that to develop a comprehensive list was not feasible. What I ended up with was a good all around representation. I then generalized it to include things not solely pertaining to me as an individual (e.g. I’m an immigrant, I can never have govt clearance).

With all the talk of identity and claims federation, this was a good way to step back and at least understand the problem space a little better. I’m sure there are other such diagrams out there but the benefit for me was to go through the process of drawing it rather than take one off the shelf.

Here’s the diagram, it turns out there are bits of us EVERYWHERE!!! Click for a larger view [LINK].

I’ve tried to group the entities (blue) by function or core competency(green). It could be inferred I suppose that similar entities would require similar forms of assurance around the claims they’re willing to accept. For example, to establish an XBox Live Gamertag doesn’t require the same degree of assurance around identity as opening a bank account. But on the other hand, Digg might be quite willing to accept my Facebook ID.

In theory these entities could share Identity Providers. I believe we’ll start to see this quite soon in the social networking space most likely through OpenSocial.

Ultimately, Identity Providers themselves will begin to exchange claims although it’s questionable if this is an appropriate model.

This is by no means a complete model. I worry that I’ll never be able to effectively manage all the pieces of me that I’m absent-mindedly handing out.

The card can then be used to obtain claims from a Simple Security Token Service. Lastly, these claims can be consumed and parsed out to complete the end to end process.

This might seem like a trivial exercise but I have not come across any other publicly available service that demonstrates the end to end flow for Cardspace MANAGED cards or one that lets you play with the claims, generate your own Cards or build your own Relying Parties against an STS in this manner.

As such I think it’s a useful learning tool. I know I learned a lot from it. I didn’t build all of this, a lot of it is hacked together from samples available at http://cardspace.netfx3.com. There were some challenges in getting it to work on an external host (vs localhost). I hope it’ll benefit the Identity Community in some way.

You can try it out at https://francisshanahan.com/cardspace
and the sample Security Token Service is here http://francisshanahan.com/sts/fssts.svc.


This code has been verified working as recently as April 2009.

1. Self-Issued Cards in which essentially you act as your own security token service and
2. Managed cards – in which a trusted third party acts as Identity Provider making assertions around your identity.

I have seen many examples leveraging self-issued cards but relatively few incorporating managed cards. There is a sample STS available on the http://cardspace.netfx3.com website but due to the complex nature of it I’ve found it challenging to set up and leverage. If you look at the message boards they are full of issues and questions involving managed cards.

To mitigate this I’ve put together a managed STS and will be hosting it here from my own website in the coming days. It’ll allow you to setup a relying party, setup claims and test values for same and even download a managed card.

I’ll also provide a generic test harness that’ll simulate your relying party and allow you to test the end to end interactions. Last thing it’ll do is provide you with the RST and RSTR structures passed around in XML as we go.

I hope this’ll be a useful service and a useful learning tool and there’ll be more to come on that in a few days. (as a side note I’m surprised Serrack or Microsoft hasn’t set this up themselves by now).

But of course there is a selfish agenda to all my work and the main reason I did this is because I wanted to understand the inner workings of a security token service. This (painful) process has shown me…

1. how it processes the Request for a Security Token
2. how it generates the Request for a Security Token Response
3. how the Cardspace Identity Selector will process that and lastly
4. how to consume the token on the Relying Party side.

When an RP indicates it needs a claim, let’s say
http://schemas.francisshanahan.com/sts/superclaim

Cardspace includes that as a required (or optional) claim in an RST. The Security Token Service reads this, (presumably) locates the value for this claim and then includes that value in an RSTR.

One thing I was surprised to learn is that Cardspace Identity Selector doesn’t actually display this value! The ID selector actually displays a value from what’s called a "Display token". Here’s where things begin to break down (for me)…

The values in the Display Token are actually what get displayed to the user.

So tying back to the Laws of Identity: The user should have knowledge and control over what gets sent to any Relying Party.

This Displaytoken seems to violate this as follows…

1. There is nothing that prevents the STS from including claims in the RSTR that were not requested in the RST.  Thus an STS could
   • ignore the "isOptional" attribute of each claim and include that information regardless.
   • Or worse still, an STS could include claim values that WERE NEVER requested. I’ve tried this with my own STS and Cardspace happily forwards these on to the RP for decryption.
2. There is nothing that prevents the STS from including Values in the Display Token that are DIFFERENT from the values in the actual claims token. So for example, it may be shown to the user that they are passing an email address of "foo@bar.com" but in reality the value being sent to the RP is actually "mypersonal@emailAddress.com". The user wouldn’t know at best until the RP processed the RSTR token.
3. Whilst the Security token is encrypted and bundled up nicely to protect its information, the DisplayToken is sent in clear (to allow the Cardspace selector to display it). Now what’s the point of protecting your claims in a security token if you go ahead and put those same claims in a Display token? How can we have user control and consent (Law #1) without violating the security of the data itself?

So it seems once again I have confounded myself with Identity by delving into the details. Perhaps it would be better to just go along with the whiteboard conversations and ws-trust what I’m being ws-told rather than ws-implement it?

It would appear based on my rudimentary investigations that there’s a potential for the first Law to be broken either through
a) Unwittingly implementing an STS that pumps in claims into an RSTR without looking at the RST.
b) A malicious STS mis-representing claims to a end user and secretly passing different information to an RP.

This for me was the kind of "Ahaah" moment that would typically not be uncovered until knee deep in an implementation and could potentially derail a project. I’m not saying this is the fault of  Cardspace, or even the Identity Meta-System. Rather I think this is a problem that’s just inherent with Law #1. As with anything I tend to find there is a lot of buzz around the high-level solution but sometimes when you dive a level deeper, you come to find out there may actually be a problem [LINK].

That’s why it’s always better to be an "I-know-it-works-because-I-tried-it,-look-my-hands-are-dirty" architect than an "I-don’t-know-what-the-problem-could-be,-it-compiled-on-the-whiteboard" architect.

I will talk to Kim[LINK] about this…