Relying Party Card Identifiers

We’ve been having a great discussion on the OSIS-general mailing list, and I wanted to save a bookmark to the thread so that I could come back later.

The thread discusses what exactly an RP should use to uniquely identify a card from a managed card provider.  The current methodology that I’ve been using with the PamelaProject RP’s was to take the isuer certificate signerkeymodulus provided in the SAML 1.1 token and the PPID and hash it together to get  a card hash that is pretty tough to replicate without the original inputs.

The problem started when I encountered a managed card that did not explicitly provide a signerkeymodulus in the token.  It turns out that I could still extract the value, but the point was made that by using the signerkeymodulus of a managed card, I guaranteed that on issuer certificate rotation, the card identifier would become invalid, and the user would have to reassociate their card.  Obviously, this is not an optimal solution.

The solution that was recommended was to generate an identifier for the issuer using the same algorithm IdPs use in section 7.6.1 of the IMI specification,  so I will give that a try right away.  I would say that this is the closest thing to a best practice out there for Relying Parties, and I would recommend that any other RP writers out there that they review whatever policy they are using;  if they are depending on signerkeymodulus, there is at least one IdP out there who does not supply the signerkeymodulus as a separate element in the token, so you’ll be having interoperability issues.  If you are storing the PPID directly, I’d also like to strongly discourage you from doing so, I would consider it just as much of a no-no as if you were storing clear-text passwords.

The thread is worth reading, if you get excited about such things ;)  You can also subscribe to the osis-general list here.

OSIS Discusses OASIS IMI Spec

Our next OSIS conference call will include an open discussion on the first OASIS information card specification, open for public review until the end of April – ISIP done growed up!

The discussion is open to everyone, and takes place during our regular weekly con-call slot at noon PST on Monday March 9, 2009 – you can either join the OSIS general list to get the call-in details or email your favorite OSIS member and ask them to forward on the details!

Hope to see you there, the more people with eyeballs on this, the happier we’ll all be in the end.

A PDF version of the spec is available here:

To join the OSIS general list, send an email to:

Update:  if you are seeing ugly “pack” errors at the beginning of the RSS feed for my post, my apologies.  I’ve disabled recaptcha until I can diagnose the problem.

Which Selector will ship with Windows 7?

WindowsSomehow, I was thinking of Windows 7 as being far far away, but apparently it could be here in as little as six months.  Now that details of what will ship under which SKU are starting to come out, I am dying to try and get the skinny from the Federated Identity team on whether Windows 7 users will get the old CardSpace bundled with .NET 3.5 sp1, or whether they will in fact get a bright shiny new CardSpace Geneva Selector!

Kim? Mike? Don? Can you give us the scoop?

As an aside, I hear that both fax services and full-image backup will be included in Windows 7 home edition — thank HEAVENS.   Whatever dim bulb removed those features from most/all of the the many and oh-so-confusing array of home versions in Vista caused me a WORLD of grief, in my capacity as reluctant amateur PC support for my family & friends.

Photo attribution:

The squeaky wheels are oiled for now…

Whenever things are this quiet, you can be sure that there is a lot of work going on beneath the surface. Just in case you don’t believe me, check out the latest version of the Bandit DigitalMe Selector: I *love* the yellow band that displays the hostname of the Relying Party you are trying to interact with, it’s a great addition. Nice work Andy!

No User Context Decisions in your Enterprise?

Photo Credit:  CarbonNYC (

Enterprise76468122_b4f810a0ac.jpg use of information cards have been a topic of great thought for me leading up to my talk at the Directory Experts Conference in Chicago this month and culminating in a panel at last week’s Novell BrainShare conference, in which Patrick Harding, Kim Cameron, Dale Olds and myself talked to the lovely Carolyn Ford on this very subject.

At DEC, the predominant opinion given to me by the experienced & capable Enterprise administrators present were as follows:

“We don’t want users to be interrupted at all — so why would we ever want or need information cards?”

If in the Enterprise you are responsible for, your users do not need to make a single context decision, if you the Administrator and your stored data can do it all in every situation — fantastic. My experience has been that many Enterprises find that the profile data they are able to serve from an Enterprise Directory or even a Meta-Directory cannot always suffice, and that measures have to be taken that deviate from the Zen of a single network profile in order to achieve business objectives. I’d like to put a few situations in front of you that I believe demonstrate common cases where undesirable measures are taken in order to get around an IT assumption that user context decisions are never necessary.

Situation #1: Do you ever have to assign two different accounts for the same application to the same user?

The only reason why a user might be issued two accounts for the same resource is because there is something critical but different about each account – and guess who chooses which account is appropriate – the user. The Enterprise cannot do the thinking for the user in this case – in fact, the Enterprise may not even know that both accounts belong to the same worker.

There are many many reasons why an Enterprise might feel forced to issue multiple accounts to a single user — it could be due to a need to completely separate conflicting roles. It could be due to a need for a certain privilege to only be available to a user under specific, acknowledged (and audited) circumstances.

Situation #2: Do your users ever have to logon to a separate network domain just to get to a specific application?

I see this at client sites every so often, often in cases where mergers and acquisitions have resulted in a fragmented Windows network. Users are forced to internally access a VPN in order to create a separate network session in order to get to a single application in an untrusted/unconnected domain still within the overall company perimeter. Maybe there is a better way to do this without Information Cards, I dunno – but it seems to me that cases like this where users have no choice but to exit their soft comfy SSO/Kerberos world using nasty clunky VPN software, using an Information Card might be a cheaper, nicer, more user friendly option.

Situation #3: Did you ever want to impress upon your workforce a sense of the solemnity of a given decision?

Currently, most workflows for approval of provisioning or service requests are implemented by a simple HTML button — “yes” I approve or “no” I reject. What if what you need in your Enterprise is something more along the lines of “I, Pamela Dingle, acting in my capacity as Manager of Business Unit X, approve this message”?

Situation #4: How many smart cards are hanging from your users’ belt-loops?

If your user is required to select the right smart card for the job, they are making context decisions – and in fact, I’d argue that you’ve already bought into the card metaphor :). In this case, chances are that the hardware solution would trump any kind of information card solution — for now. In the future, as information cards become more integrated with physical devices, the line may get awfully blurry…

Perhaps situations like the ones I’ve described above might influence you to take a closer look at information cards. Perhaps, there still isn’t enough to convince you yet. That’s ok – there is a lot more to come, this is just a small piece. I’d love to know what people’s experiences are in general around the concept of the need for user context decisions in the Enterprise – are such decisions as diametrically opposed to common SSO/IWA administrative philosophies out there now as I imply here?