Nikolejsin is spreading the word on Claims based Identity to the Canadian public sector. I had a quote and Pamela Dingle, Mary Ruddy and Rob Blakley are also in there. August company for me.

http://www.thestandard.com/news/2009/09/16/case-claims-based-identity-management

http://www.itworldcanada.com/news/the-case-for-claims-based-identity-management/138760

http://news.idg.no/cw/art.cfm?id=C46053C8-1A64-67EA-E40DEA02CB302FD4

It seems like it came back sometime around 10 o’clock eastern. I immediately noticed things weren’t working on TweetARun.com but Twitter was at least providing an authorization token.

A bit of debugging revealed that Twitter no longer respects the oauth_callback parameter passed in by the relying party. It seems to be just directing the token back to the domain that requested it rather than the page in the oauth_callback. I checked the spec and sure enough oauth_callback is there: [LINK] but maybe we’ll see an update in the near future.

Anyway, glad to get oAuth back. I far prefer it to OpenID and am looking forward to pressing on with TweetARun.com.

This just highlights the dependency we as Relying Parties have on Identity Providers.

http://TweetARun.com is a nice simple little site that purposefully avoids the need to register or store passwords by implementing Federated Single Sign On with Twitter through Open Auth. That’s a lot of words but all it means is you never ever register on http://TweetARun.com. Rather you click a button on http://TweetARun.com which sends you over to Twitter. Then you simply Grant permission to http://TweetARun.com to access your profile. This action sends you back to TweetARun.com with what’s called an authorization token. http://TweetARun.com then exchanges this token for an Access Token which it can then use to update or retrieve information from your Twitter account. It’s a nice scheme.

Now you might say this just highlights the need to have two forms of authentication, one for the partner site and one for when the partner site is down. Think of it, TweetARun.com is not down right now, it’s fully functional as can be seen here (http://TweetARun.com/FrancisShanahan) so why should users be locked out? I’m on the fence about this as I really want to avoid the proliferation of information, specifically userid and password.

Let’s see how long the outage lasts and then I’ll decide.

foolstr is innovative in that it relies on OpenID as its form of authentication. This means foolstr doesn’t invade your privacy and registration is a snap. It’s also completely anonymous. Things like Passwords or Email addresses, we don’t need ‘em. Your email or password is never sent to Foolstr, you don’t have to remember a NEW password, you don’t have to remember ANYthing. Try it and see!

It’s a fun site and we want the barrier of entry to be small. You can post content without even registering and so far there is some interesting content.

From a technical side this site is another experiment, this time dealing with OpenID to determine just how viable this technology is. So far it seems sound for this level of authentication. The question is will the public understand it and be comfortable with this as a means of authentication. We’ll see. I’ve also hooked up the Yahoo Term Extraction API for content analysis and Google Analytics for Traffic.

So blog about it, Facebook it, Digg it, tell your friends, share your ideas and opinions and vote on what’s there. Let’s see what the fools know…

Foolstr’s still in pre-alpha, with many kinks still being ironed out. If you find a bug, post back to http://foolstr.blogspot.com or use the contact page at foolstr.com.

Now get out there and tell us something we don’t already know!!!
HTTP://FOOLSTR.COM

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

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]