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

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.

A number of you have emailed me directly and some have commented publicly with some thoughtful insight and I thank you for that. Vittorio has written a very thoughtful and detailed response on his own blog [LINK].

Going back to my original question which was "Does the DisplayToken violate the First Law of Identity?" I am not convinced it does. What I think I am discovering is that the First Law of Identity is not necessarily enforced.

In Kim’s words[LINK]

"Those of us who work on or with identity systems need to obey the Laws of Identity."

For me, being Irish Catholic (and riddled with guilt as a result) I take a very hard-line approach when you start talking about "Laws". For example, I expect the Law of Gravity to be obeyed. I don’t view it as a "Recommendation for the Correct Implementation of Gravity". And the Universe assures me in large part that gravity will be obeyed right? Well for the most part, but you get my point.

So rather than a recommendation around user control and consent; I would rather it be obeyed and enforced by the protocol. Here’s where things get tricky as we’re trying to implement an Identity Meta-System and today, as Vittorio says, I may have a "coconut token" and tomorrow I might have some other token format.

Will the paradigm of RST/RSTR exchange change? Probably no, or not much.

Is there any dependency between the RST and the RSTR today? This I was surprised to learn is a "No".

What I think would solve the issue in some small part is to tie the RST to the RSTR in such a way that the STS cannot possibly generate an RSTR that includes claims other than what the RST requested.

How to support user consent?

To have user consent, the user needs to see what’s being said about them. So again I think you need to tie the DisplayToken to the RST or RSTR somehow.

Now, what about privacy?

That’s a tricky one and likely not 100% solvable but the approach of masking out aspects of the data seems to be what most people (Matt Ellis) suggest when I ask this question.  I don’t think it scales.

Today we mask out credit card numbers, providing only the last 4 digits. In other scenarios we mask out social security numbers again with the last 4 digits. Nowadays the combination of birthdate, zip-code and Surname "marketers can uniquely identify almost the whole population" [LINK].

Will the Displaytoken mask out these values also? will we end up with a DisplayToken that looks like this:

First Name: ****cis
Last Name: *****han
Date of Birth: *1/*1/*2
Zip Code: ***69
Email: f*********@mail.com

Huh??? This could get confusing right? And does it work long-term? No. Even today, in many cases folks DON’T NEED your social security number, they only need the LAST FOUR DIGITS!!!

As EJNorman on Vittorio’s blog states; "The question is: why shouldn’t a user be able to inspect what’s being said about him and sent to a relying party to verify that it’s what was expected?"

I think this is at the crux of Law #1. Control and consent right? If a user can’t see what’s being said about them they just have to trust the IdP’s STS. Anytime you "trust" you give up "control", no?

It seems to me that if we are to ask users to "trust" the IdP then we are headed towards establishing a rating or assurance level around the notion of an Identity Provider. Just as not all STSs are IdPs and not all certificate authorities are high-assurance certificate authorities, not all IdPs will be well implemented, reputible or trust-worthy IdPs. The reasons for this are not all malicious as I earlier stated:

1. An STS may unwittingly pump in claims into an RSTR without looking at the RST.
2. As Vittorio points out; an STS may choose not to verify the credentials in the RST
3. Without authentication, an STS might just give out tokens to any RP on your behalf (chances are very low and this IdP would go out of business fast).

The possibility of these things happening is there as the protocol allows it.

Coders/developers on the front line take the path of least resistance almost ALWAYS. Code and ship. If there’s a way to implement something that’ll get the RST/RSTR exchange working with an RP and IdP that doesn’t enforce or prevent 1,2,3 as listed above then my fear is we will end up with IdPs out there that are not well implemented and as a user, we will have little to no way of detecting the good IdPs from the bad.

One way to work towards a solution is to have more heads looking at this across both the TECHNOLOGY (Ws-Trust/Ws-Fed etc.) as well as the HUMAN ASPECT (Identity Laws).

I’m not sure how to solve this. I’m not sure if it’s a fault inherent in the Identity Meta-system or if it’s just a fact of life we have to live with.

I would never want to put the elegance of a meta-system design and accommodation of potential future token types ahead of supporting Law #1.

I think I need to think about this some more…but I feel like I’m getting it.

I have been playing with Cardspace, .NET 3.x and the ID meta system for some time now. Probably 18months. In March of this year I got the chance to demo an interesting proof of concept with this technology at the IDA conference in Redmond. That was fun and is one of the last memories I have of life before Karen’s diagnosis.

So it’s exciting to see this technology turn the corner. Roll out to 300MM users is no small feat and although it’s still in Beta I have every confidence that this stuff headed in the right direction.

Incidentally, I came to know of this through Kim’s blog [LINK].