Category: Identity Metasystem

Cobbler's children

Here's an “ouch that hurts” posting by Jackson Shaw at Quest:

I received this email today regarding my identity partner's account that I have at Microsoft. Isn't it unfortunate that given Active Directory Federation Services (ADFS) and CardSpace that I have to do this?

Shaw, Jackson, The password for the extranet account issued to blah\JShaw will expire on Mar 15 2007. Please proceed to the following URL to change the password: https://Home.EP.Microsoft.com/login.aspx

NOTE: Failure to change the password before the expiration date will result in the account being locked and access will no longer be provided.

Thank you, The Extranet Management Tool Team

For assistance, please contact your administrator, site owner or support team.

I have zero time to figure out who my administrator, site owner or support team is.

I do know my Quest userid and password and wouldn't it be nice if that just worked??

Jackson is right.  Everything about this is bizarre.  I too love those “contact your administrator” messages – best of all, when I'm the administrator, but in all other cases too. 

Anyway, we are now getting close to the point where Microsoft marketing and other sites will start to light up.

With the sheer number of sites we have, and the attacks on our perimeter, our IT guys have to go about this in an organized way.  I spoke with Microsoft's internal IT security architects not long ago and was amazed at how well they have thought through the implications of the claims-based approach, privacy issues, uses for CardSpace, and so on. 

Meanwhile a lot of our sites are tied to Windows Live ID, so when it turns on Information Card support, the benefits should start to be widely felt.

Today Jackson did a piece outlining the Laws of Identity and  concludes:

I installed WinFX the other night on my Windows XP system and created my own Information Cards and then used one to logon to Kim's blog – it worked! [He's so surprised? – Kim]

Now if I could a Quest property or two to accept either OpenIDs or InfoCards…

Hey, Jackson – let's get some live company-to-company interaction happening with the technologies we all want to introduce.  Why don't we approach the Extranet Management issue from both ends – you from the quest end, me from this end?  Maybe others would want to jump on as well… The proof of the shoe is in the walking.

P.S.  Why don't you talk with Pamela about getting onto blogging software that accepts Information Cards too?  Mike Jones has done it.

UPDATE: Here is a posting on our progress in getting ADFS (Federation Services) going on our extranet, so the collaboration proposed above should be “way simple”.  And it's good to see that Brian Puhl not only listened to your original comment but did so much to move things ahead.

newtelligence CardSpace API

Sergey Shishkin reports that a new developer's kit will be released by newtelligence AG.

newtelligence AG announces plans to release the newtelligence CardSpace SDK, a Software Development Kit for Microsoft Windows CardSpace. The SDK, based on newtelligence expertise in information security, will help developers build more robust CardSpace-enabled application on the .NET platform – with ease.Microsoft .NET Framework 3.0 was released in November 2006 and introduced Windows CardSpace – a user-centric digital identity solution.

CardSpace allows developers to leverage federated security and single sign-on in their solutions. As a leading security expert company, newtelligence investigated .NET Framework 3.0 and Windows CardSpace starting from its early, pre-released versions and developed technology samples to clearly demonstrate to customers the underlying technology as well as provide best practices for its use.

Although CardSpace is based on the standardized web service security protocols (WS-* standards), developing CardSpace-enabled applications is challenging. Developers have to possess solid knowledge not only in web service security protocols but also in cryptography and XML.

newtelligence SDK for Windows CardSpace will provide a comprehensible API for key CardSpace application scenarios: Programmatic creation of managed information cards; requesting and validating security tokens in Microsoft Windows and web applications; and issuing security tokens. Use of the API will increase software security and developer productivity: Writing secure software is simplified and less software coding is required to achieve the desired, secure functionality. To aid understanding of the SDK and of CardSpace in general, a reference application and additional code samples covering different aspects of the API usage will accompany the SDK.

The newtelligence CardSpace SDK will contain complete source code of the API and is intended for personal use only. For more information regarding availability, licensing or reuse of the SDK, please contact us.

One of Sergey's readers comments:

How about just releasing it instead of announcing the announcement 😉

Sergey responds:

Dominick, the work is in progress now. The release is of course the goal 🙂

I'm glad to see Dominick so itchy.  Sergey says he will host a discussion about the API on his blog.

Mike Jones and self-issued.info

Everyone who has met me has probably met my colleague Mike Jones, who put his work as a researcher at MSR on hold because he got so interested in user-centric identity and Information Cards.  He has now started to blog – check out the InfoCard showing Mike and Dale onstage at Novell Brainshare. 

For those new to Information Cards, you don't normally share an InfoCard with someone else.  This was truly a “they did it because they could” moment… 

On March 21st at Novell’s BrainShare 2007 conference, Dale Olds and I co-presented the session “Who are you? From Directories and Identity Silos to Ubiquitous User-Centric Identity”. Our presentation was a brief history of digital identity solutions, ranging from a password per application to interoperable user-centric digital identity using the Information Card metaphor and several steps in between.

demo self-issued cardThe coolest thing in the session was the first public demo of the Bandit/Higgins cross-platform Identity Selector. During the demo Dale and I both used the same self-issued Information Card (that I created on the BrainShare show floor 🙂 ) to log into a Bandit relying party site, Dale from Linux and me with Windows CardSpace. As Dale and Pat Felsted blogged, two days later the Bandits also demonstrated their selector running on the Mac. Also see Pat’s post on the Details of the Cross Platform Identity Selector.

Great progress towards enabling everyone to answer the question “Who are you?” online with the Information Card of their choice!

BTW, you'll see that Mike, like me, is using pamelaware for WordPress – and accepts comments through infocards.  If you use WordPress, you should check it out.

Delegation tokens and impersonation

I've been asked to clarify a couple of points by Devlin Daley and Bryant Cutler, who are studying with Phil Windley.

Delegation tokens 

Delegation tokens, as you've described them, (according to one of Dale Old's recent posts) are not yet implemented in CardSpace.  Is that accurate? Is it soon to be added to specification or is it still a work in progress?

I like Dale's piece, but think the “not yet implemented” statement might lead to confusion. 

One of the key characteristics of CardSpace is that it has no idea what kind(s) of token it is carrying.  It's hard to get this across – the practical meaning isn't obvious.  But your question about “delegation tokens” provides  a good concrete example:  delegation coupons can be conveyed through CardSpace without any changes or extensions to it.  This doesn't mean anyone is doing so yet.  That is likely what Dale is talking about. 

I've actually been thinking of putting together some demo code to show how this would work.  If you look at my “HelloWorld Card” tutorial,  you will see that rather than requesting and sending a “HelloWorld Card”, the relying party could easily be requesting a delegation coupon.  So CardSpace is actually ready for “delegation coupons”.

One can then ask what a delegation coupon would look like in concrete terms.  What's the best format for the (possibly multiple) constituent tokens?  The blogosphere discussion about delegation shows lots of people are thinking about this, but so far we haven't built the “early implementations” that let us explore the issues and problems concretely enough to emerge with a new standard.  I would be interested in learning about research systems built in the academic community to explore this territory – perhaps you can share your research with us.

Impersonation

Devin and Bryant continue:

We've been bantering about the idea of delegation vs. impersonation. Clearly impersonating someone without them knowing is wrong and a serious problem. But, is impersonation “bad” if I give my express permission for someone to do so? (assuming there is a mechanism for revoking this permission).

In your Powell's and Amazon example, what if I don't want Powell's to know that I am supplying this information to Amazon? Obviously there are cases where we want to let others know that services are acting with our permission. Perhaps there are cases where we don't want to disclose that. Is granting the choice to me more user-centric?

You are quite right that, as per the first law of identity, the choice of what to disclose must always be in the hands of the user.  Further, if a user wants to delegate to a machine the ability to “be her”, that should be possible too.  Let's call it extreme delegation.  Our job is not to tell anyone that they should live in some particular way.  We might, however, have the responsibility of pointing out the technical dangers of this extreme, perhaps even recommending some interesting science fiction readings…

But I'll point out that it isn't necessary to do impersonation to achieve the goal you want to achieve in your example – preventing Powell's from knowing that you are supplying information to Amazon.  In fact there are two ways to use delegation to do this. 

The first is simply to create a coupon saying, “the holder of this key has the right to see my Powell's behavior”.  Then you give Amazon the coupon and the key.  In return, Amazon might give you assurances about how it will protect the coupon.  Meanwhile, it can retrieve the information it wants without revealing its identity.

Or you may wish to have an agent of your own to which you delegate the ability to assemble your behaviors, and the right to pass them on according to your dictates.  I personally think this is the most likely option since it provides optimal user control.  But even in this case, designing secure systems means limiting the capabilities delegated to that particular piece of software, rather than “making it into you” by having it operate in your identity.  There is zero need for impersonation.

Your use case of information hiding can be handled without departing from my delegation maxim:

No one and no service should ever act in a peron’s identity or employ their credentials when they’re not present.  Ever.  

Putting several threads together, the user should act through a transducer to delegate to well-identified processes.

Delegation requires multiple tokens

ID Maan comments:

Little puzzled with your views respect to SAML:

“It is a lot cleaner for this scenario than the single-token designs such as SAML, proposed by Liberty, or the consequent “disappearing” of the user.”

As I understand WS-Trust is a token agnostic protocol. Delegation on other hand can be essentially considered as the capability of the securty token. So, isn't WS-Trust in a way dependent on the security token capabilities to provide for delegation? In other words, if you state SAML is insufficient to solve delegation problem, so is WS-Trust protocol that uses SAML tokens?

No wonder he is puzzled.  I should have been clearer.  Let me try again.

We all agree the SAML token is a fine and good way of expressing sets of claims.

But beyond the token, there is the SAML protocol – one way of moving SAML tokens around. 

I think the SAML protocol suffers from having a single-token design.  Why?

I don't think delegation problems can be solved through a single token.  Once you are expressing the identities of both a user and a delegate, you need to be able to request and convey two (or more) tokens – in the sense of integral things from separate sources.  In the simplest case, one represents the user, one the delegate.

To be clear, I wasn't hitting on the SAML protocol in all its applications.  I was arguing that WS-Trust, which has the ability to move and request multiple tokens simultaneously and establish relationships between them, solves the delegation problem more cleanly from an architectural point of view. 

When SAML was being elaborated, before the user-centric identity wave, we saw the user as being represented by the portal service.  She had no independent existence.  So you didn't need multiple tokens.

Since Identity 2.0, all this has changed.

Bandits strike at BrainShare

Incredible news from Dale Olds’ VirtualSoul at Novell:

This week was Novell’s Brainshare conference. It’s a big deal for Novell folks and it’s a great event. It gives us a place to show off new technologies like the emerging Internet identity systems and some of the recent work that we have done on the Bandit team.

Our most significant demo this year was shown during the technology preview keynote on Friday. The whole series of demos is interesting — I especially liked some of the Linux desktop stuff — but if you want to just skip to the infocard stuff, it starts at about 40 minutes into the video.

For those who may want to know more detailed information about what the demo actually does, let me give some background information here:

There were 3 new open source components written by Bandits and made available this week:

  • A fully open source, cross platform identity selector service was contributed to Higgins. Written in C++, this Higgins ISS runs as a daemon (no UI) and provides core infocard selector service: it accesses multiple card stores, enumerates available cards, matches cards based on requested claims, and interacts with the appropriate STS to get a token. It is almost complete on support for personal cards, with an internal STS, etc. The real deal.
  • A UI process for the Higgins ISS. It is currently written in C#, runs on Mono, and leverages much of the management UI of the CASA component of Bandit.
  • A new OpenID context provider was contributed to Higgins. This context provider plugs into the Higgins IdAS and allows identity data to be accessed from any OpenID Provider. What this means is that, with no change to the Higgins STS code (since the STS uses IdAS), we could set up a demo such that infocards can be generated from any OpenID identity. In other words, using the Higgins STS and the new OpenID context provider, I can access any site that accepts infocards with my openID account.

So what Baber showed in the demo:

  1. A fully functional, native infocard selector running on the Mac.
  2. He accessed a shopping site with an infocard generated from an OpenID account. Put some things in the cart and logged out.
  3. Baber switched to a SUSE Linux Desktop machine. Fully functional infocard selector there as well. Accessed the same site with an OpenID infocard and see stuff in his cart from the Mac session.
  4. Goes to check out. The site asks for a card with different claims, needs a payment card.
  5. The Higgins Infocard selector supports multiple card stores. In this case Baber selects a credit card from a card store on his mobile phone via bluetooth.
  6. He authorizes a (hypothetical) payment and the online shopping site (the relying party) only gets his shipping address and an authorization code from the credit card.

It’s a simple demo, and easy to miss the number of technologies and interactions involved, but this is the kind progress that we have been working towards for a long time.

The Bandits are happy and tired.

An example of delegation coupons

Even if the true meaning of uber-geek is “incomprehensible”, my last comment on the use of delegation in VRM was a real winner in terms of terseness. I was discussing Whit's notion that he wanted to give Amazon access to his behavior at Netflix, Powell's and lastfm – the goal being to improve Amazon's relationship with him by revealing more about himself as a complete person. So I'll try to unfold my thought process.

If you ponder the possible architectures that could be used, it becomes clear, as usual, that the identity aspects are the hardest. Let's build a little picture of the parties involved. Let's say the user (I know, I should be calling Whit a “customer”), shares his behavior with Amazon and Powell's. Now let's call some subset of his behavior at Powell's “BP“. Whit would like an outcome that would be modelled in the following diagram, assuming for the moment that U->A:BP just represents Amazon asking Powell's for the customer's relevant information.

But how does Powell's know that Whit really wants it to release information to amazon.com but not snooper.com? How does it know that the amazon.com which calls for information is really the same Amazon that Whit was dealing with? Why should Powell's ever take the privacy risk of releasing information to the wrong party? What would its liability be if it were to do so? Can it protect itself from this liability?

When I mentioned delegation, I meant that while the user is “behaving” at Amazon, it gives Amazon a “coupon” that says “User delegates to Amazon the right to see his Behavior at Powell's”. I represent this as U->A:BP, where:

  • U is the user;
  • A is Amazon;
  • P is Powell's; and
  • B is behavior

Amazon can now present this coupon to Powell's, along with cryptographic proof that it is the “A” in the coupon. By retaining this coupon and auditing any release, Powell's can indemnify itself against any accusation that it released information to the wrong party – and better still, actually defend the user's privacy.

‘Breaking up is hard to do.’

I have left two of the most important questions for another time. First, is it really necessary (or advisable) for Powell's to know that the Whit is sharing information with Amazon, rather than “some legitimate party”? Second, how does Whit revoke the permission he has granted to Amazon if he decides the time has come for them to “break up”?

But without even opening those cans of worms, it should be evident that, for reasons of privacy, auditablity and of liability reduction, everyone's interests are served by making sure no service ever acts as an end user. In this example, Amazon continues to act as Amazon, and even if its access is one day anonomized, would would always be identified as “the user's delegate”. The approach constrasts starkly with current approaches – as spooky as they are cooky – in which users release their credentials on “good faith” and eventually, if enough secrets are shared, anyone can be anyone.

Note:   The notation above is my own – please propose a better one if it is just as simple…

Temporary problems logging in?

A number of people have had problems logging in to my blog from non-CardSpace identity selectors.  Eric Norman writes:

As of the upgrade today, I can't get to Kim's blog any more. The same thing happens with either Firefox or Safari.

When I click on the link to log in with an InfoCard, I get redirected to an error page that says I submitted an invalid one (see attachment).

I suspect that the problem is in on the WordPress side since it happens with two separate browsers, but I suppose it's possible that they both share some bad code.

In any case, I would be glad to help diagnose the problem…

I do come from an academic environment and we here do care a lot about interoperability across platforms. While I understand that all this code is still very experimental, I am faced with the problem that it worked yesterday and doesn't work today.

As long as I'm trying to help debug, I'll mention one other thing.

I don't know if this is still a problem since I can't get far enough any more. Neither of the above identity selectors have the ability to export and import cards, so I just had to install a new card on each. Whenever I would switch browsers, I would have to go through  the email verification bit again. This could get rather noisome.

It appears that the server side just remembers the last card that contains an email address instead of all of them.

So first, let me say I threw my blog into Pamela mode as part of the Pamela beta – hoping people who come here would be willing to put up with any inconvenience.  Maybe I should have asked first!  And I probably should have asked for Project Pamela's permission as well.  What can I say?  I'm an architect and I get excited about things.  I've really wanted to get on to production code. 

Make a note not to hire me as your operations manager…

We'll get it sorted out ASAP.  I'll post when we get things fixed.  In the meantime, if you use the Safari or Firefox Java identity selectors please use my i-name (or my email) to send your comments and I'll post them.

In terms of Eric's comment that it should be possible to register several cards at once, I know Pamela Project wants to work on that.

Finally, we need a cross-vendor automated test suite that includes tokens produced by everyone's implementations.  All of us will want to test with such a resource.

Drilling further into delegation

Still further to my recent piece on delegation, Eric Norman writes to give another example of a user-absent scenario.  Again, to me, it is an example of a user delegating rights to a service which should run under its own identity, presenting the delegation token given to it by the user.

For an example of user-absent scenarios, look at grid computing. In this scenario, a researcher is going to launch a long-running batch job into the computing grid. Such a job may run for days and the researcher needs to go home and feed the dog and may be absent if a particular stage in the job requires authentication. The grid folks have invented a “proxy certificate” for this case. While it’s still the case that a user is present when their “main” identity is used, the purpose of the proxy cert is to delegate authentication to an agent in their absence such that if that agent is compromised, all the researcher loses is that temporary credential.

Perhaps this doesn’t count as a “user absent scenario”. Nevertheless, I think it’s certainly relevant to discussions about delegation.

I agree this is relevant.  The proxy cert is a kind of practical hybrid that gets to some of what we are trying to do without attempting to fix the underlying infrastructure.  It's way better than what we've had before, and a step on the right road.  But I think those behind proxy certs will likely agree with me about the theoretical issues under discussion here.

As an aside, it's interesting that their scheme is based on public key, and that's what makes delegation across multiple parties “tractable” even in a less than perfect form.  I say public key without at all limiting my point to X.509.

With respect to the problem of having identities on different devices, Eric adds:

Um, I think one of the scenarios Eve might have had in mind is the use of smart cards. A lot of people think that the “proper” way smart cards should operate is that secrets (e.g. private keys) are generated an the card and will reside on that card for their entire life and cannot be copied anywhere else. I’m not commenting on whether that’s really proper or not, but there sure are a lot of folks who think it is, and there are manufactures that are creating smart cards do indeed exhibit that behavior.

If users are doing million dollar bank transfers, I think it makes sense to keep their keys in a self-destroying dongle.  In many other cases, it makes sense to let users move them around.  After all, right now they spew their passwords and usernames into any dialog box that opens in front of them, so controlled movement of keys from one device to another would be a huge step forward.

In terms of the deeper discussion about devices, I think we also have to be careful to separate between credentials and digital identities.  For example, I could have one digital identity, in the sense of a set of claims my employer or my bank makes about me, and I could prove my presence to that party using several different credentials-in-the-strict-sense:  a key on smart card when I was at work; a key on a phone while on the road; even, if the sky was falling and there was an emergency, a password and backup questions.

If we don't clearly make this distinction,, we'll end up in a “fist full of dongles” nightmare that will even make Clint Eastwood run for the hills.  When I hear people talk about CardSpace as a “credential selector” it makes my hair stand on end:  it is an identity selector, and various credentials can be used at different times to prove to the claims issuer that I am some given subject.

Speaking of smart card credentials, one of the big problems in last-generation use of smartcards was that if a trojan was running on your machine, it could use your smartcard and perform signatures without your knowledge.  Worst of all, smartcards lend themselves to cross-site scripting attacks (not possible with CardSpace).  To me this is yet another call to have the user involved in the process of activating the trusted device.

Identities on multiple devices

As I said here, I want also to look at a second strange claim by Eve: 

On another issue, she noted that OpenID 1.0 has a vulnerability in that it leaves users’ identities open to possible correlation by unauthorized third-parties.

But that CardSpace has a vulnerability of an opposite but equally problematic nature. Given that each CardSpace is associated with a particular client device (i.e., a particular desktop, laptop, or mobile phone running Vista), and given the fact that each user might have multiple such devices, each with a multiplicity of cards running on them…that the more such devices, cardspaces, and i-cards multiply for a given user, the more difficult it will become for a particular user to correlate the various fragments of their identity across their own personal “space.”

This really strikes me as bizarre.  Maybe Eve was asleep while the entire world learned to copy mp3s onto their music players and carry them around?  Duh.  We know how to move files from device to device.  In fact there are probably many hundreds of millions of people who can do it better than either Eve or I can.

The idea that this is the big vulerability of CardSpace boggles my mind.  The whole criticism “Does not compute.”

Then again, I actually use Information Cards, and move them from device to device, so maybe that's why it's so clear to me how easy it is to do. 

Let me share the exact experience I have installing the Information Cards from my PC's CardSpace onto my mobile phone.

 Moving Information Cards from device to device

1)  I open up CardSpace and select Back Up Cards.  This will create a file containing my cards.  I decide to call it “cardset”.

2) I copy ‘cardset’ to my phone and click on it:

3) The phone asks for the password I used to protect my file

 

4) It verifies I'm importing the right cards

5)  And now I have the same cards on my phone device as on my PC.

How hard is that?  It would be the same process copying the file to some other device.  It works fine.  As easy as getting a word document or powerpoint or mp3 from one place to another.  Dongle anyone?  How about email?

Still, the uberpoint is this:  once Information Cards live on my phone, they go whereever I go. 

There are lots of ways phones can potentially talk to other devices.  So who says we have to copy our cards to all our devices once they live in a secure, personal device like a phone that we always have with us?

NOTE:  I want to point out that the mobile implementation of CardSpace I'm showing here is NOT a product.  It's a way of learning about the issues, and collaborating with colleagues in the world of telecom and secure portable devices.  But hey!  It's still a lot of fun.  More later.