Ben Laurie on Selective Disclosure (Part 2)

In introducing people to his Selective Disclosure paper, Google's Ben Laurie says: 

In fact, there are many ways CardSpace could violate the laws, but there is one which it is currently inherently incapable of satisfying, which is the 4th law – the law of directed identity – which says, once you’ve fought your way through the jargon, that your data should not be linkable.

Ben doesn't like the term “omni-directional identifier”, which is certainly his prerogative.  But speaking of jargon, note that according to the Oxford English Dictionary, Ben's word “linkable” doesn't actually exist… 

Meanwhile “omni-directional” is a real word from the field of telecommunications (isn't that what we are working in?)  It means “of equal sensitivity or power in all directions”.  Similarly, “unidirectional” means “moving or operating in a single direction”.

So I think the Fourth Law is precise enough:

A universal identity system must support both omni-directional identifiers for use by public entities and unidirectional identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

The word “discovery” is again used in the technical sense of making it possible to locate and rendezvous with other entities.   The goal here is to embrace the range of use cases I discussed in part one

Ben argues that CardSpace breaks this Fourth Law.  In this he is wrong.  I suspect he is confusing CardSpace, which is just a way of selecting between identity providers, and the identity providers themselves.  Let's get that really straight.

CardSpace is one component of the Identity Metasystem – by which I mean a distributed mesh of parties asserting and depending upon identity.  CardSpace informs the user about the identity providers that can satisfy a given relying party request, and provides a mechanism to tell the user what information must be released to the relying party in order to gain admission to the site.  But the identity selector does not itself make assertions or sign them cryptographically, or do anything that introduces linkability or traceability.  If linkability is introduced, it is because of the choice of the identity provider people use with the the system, and of the cryptographic systems they employ.  

Privacy characteristics of the self-asserted Identity Provider 

While CardSpace is an identity selector, we have built it to include a self-asserted identity provider as a way to bootstrap the system.   So what are the privacy characteristics of this provider?

  • It emits no identifiers that allow the identity of the user on one system to be linked to the identity of the user on any other.  
  • A different signing key is used at each site visited so keys and signatures cannot be correlated.
  • Relying parties cannot collude with this identity provider because it is run by the user. 

So the Identity Provider that ships with CardSpace does not break the Fourth Law either.

Managed Card Providers 

Now let's talk about managed card providers, and think about other systems such as Liberty or Shibboleth or OpenID or SAML or WS-Federation in browser mode. 

These systems always identify the relying party to the identity provider.  They do so because they need to tell the identity provider how to redirect the client's browser back to the relying party.  So they are what I call panoptical by design.  There is zero collusion required for the identity provider to know what is being asserted where – that knowledge is designed right into the system.

CardSpace breaks with this paradigm, and I hope Ben comes to recognize this. 

To support use cases where we do NOT want linkability, CardSpace hides the identity of the relying party from the identity provider.  If we had built it without this feature, it too would have been “panoptical by design”.  But we didn't do that.  We built it to conform with the Fourth Law.  In other words, CardSpace does not provide unnecessary handles to facilitate linkability.

How does CardSpace hide the identity of the relying party?  It associates some random information – unknown to the identity provider – with each Information Card.  Then it hashes this random information (let's call it a “salt”) with the identity of the site being visited.  That is conveyed to the identity provider instead of the identity of the site.  We call it the “Client Pseudonym”.  Unlike a Liberty Alliance client pseudomym, the identity provider doesn't know what relying party a client pseudonym is associated with. 

The identity provider can use this value to determine that the user is returning to some site she has visited before, but has no idea which site that would be.  Two users going to the same site would have cards containing different random information.  Meanwhile, the Relying Party does not see the client pseudonym and has no way of calculating what client pseudonym is associated with a given user.   

The question now becomes that of how identity providers behave.  Given that suddenly they have no visibility onto the relying party, is linkability still possible?  I'll discuss this next.

Just lie so you can sell your product

David C pointed me to this document as being typical of how conventional biometrics are being sold to the schools.  It represents the minutes of a meeting of the Marlin County School Board in Stuart, Florida:

Members Present
Lorie Shekailo-Chair
Laurie Gaylord-Vice-Chair
Susan Hershey
Nancy Kline
Dr. Sara A. Wilcox, Superintendent
Doug Griffin, School Board Attorney

Members Absent
Dr. David Anderson

Staff Present
Hank Salzler, Ruth Pietruszewski, Cathleen Brennan, Kerry Lewis, Sean Lewis, Linda King, Ray Parrish, Steve Weil, Rae Hollenbeck, Deana Newson, Rodger Osborne, Teresa D’Albora, Willie Sauls, Jeff Haertjens, Gail Williams, Marilyn Gavitt, Kathy Ritch

Public
None

Press
PBPost – Rachel Simmonsen
Stuart News – No Representation

MCEA – No representation
AFSCME – No representation

Call to order by the Chairman and Pledge of Allegiance to the Flag of the United States.

1. Presentation on Biometric Finger Imaging (COPY ATTACHED)

Rae Hollenbeck, MCSD Director of Food and Nutritional Services, described a new technology called Biometric Finger Imaging that has only been available about six months. She showed a PowerPoint presentation. Finger images are scanned and stored on the computer network, so that children no longer need cards. Rae explained how children forget and lose cards as they run off to school in the morning. This backs up the lunch line and creates managerial time reprinting meal cards. Rae commented that already this school year 4,000 meal cards had been reprinted just at the middle schools. The cards become unsanitary, because the children put them in their mouths. To solve these problems, schools are using biometric scanners in the cafeteria. The student places their index finger on a scanner.

The Perfectmatch software extracts the small marks on their finger tip and creates a template. These marks are transformed into a binary number that is encrypted from the time it is captured to the time it is stored on the database, and the finger image is discarded. The binary number will become the student ID number. Only the numbers are retained and it is impossible to recreate a fingerprint image from this data. This is a closed system, and it is not accessible from the internet. The biometric images cannot be used by law enforcement for identification purposes. Only a mathematical algorithm remains in the system after registration, not finger images. Rae stated that she would like to pilot this program at Murray Middle School in January 2007.

The program would not be mandatory.  Parental choice would be offered if parents wanted to opt out of the program.

The hardware would run somewhere around $200 per line. The total cost of hardware and software would run about $1500.00 per cafeteria. The new technology would improve sanitation of the line, increase the speed of the serving lines, and reduce staff time dealing with missing and lost cards, forgotten ID numbers, and reprinting cards.

2. Open to the Public
No one from the public requested to speak.

Biometric Finger Imaging Workshop Minutes
Tuesday, October 17, 2006 – 6:00 p.m.
Page 2 of 2

3. Open to the Board
Lorie Shekailo suggested withholding “Open to the Board” and doing it at the Regular Board meeting which followed.
Board members agreed.

There being no further business to bring before the Board, the meeting was adjourned at 6:24 p.m.
_______________________________

CHAIR (Lorie Shekailo)
_______________________________

SECRETARY (Sara A. Wilcox, Ph.D)

The sanitation argument is new to me.  Imagine – stressing the sanitation benefits of   having every child in a middle school put his germy little finger on the same sensor as every other child…  Seems like a good way to isolate viruses, doesn't it?  A lot better than giving each child a paper card!

The idea of children putting their cards in their mouths sends chills down my spine.  In contrast, they would never stick their fingers in their mouths, and then swipe them on the finger print reader for distribution to all the other kids.  Talk about a shared secret!

But let's brush this aside and move on to the old saw – the lie:

The biometric images cannot be used by law enforcement for identification purposes. Only a mathematical algorithm remains in the system after registration, not finger images.

If you want to find out who owns a fingerprint, just convert the fingerprint to a template and do a search for the template in one of these databases.  Call the template a binary number if you want to.  The point is that all you need to save in the database is the number.  Later, when you come across a “fingerprint of interest”, you just convert it to a number and search for it.  Law enforcement can use this information – and so can criminals.

It drives me nuts that people can just open their mouths and say anything they want about biometrics and other technical matters without any regard for the facts.  There should really be fines for this type of thing – rather like we have for people who pretend they're a brain surgeon and then cut peoples’ heads open.

LeaveThemKidsAlone has an annotated commentary here.

And if you haven't see it yet, don't miss this little movie clip.  It will boggle your mind.

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.

Identity Selector Permutations

Check out this interesting set of Identity Selector Permutations posted by Paul Madsen on his ConnectID blog.

In trying to make sense of the various combinations of OS, browser, plugins etc for enabling a client with a Cardspace compatible identity selector, I created the following graphic (click to enlarge…)

Caveat: It's almost certainly wrong in places, and doesn't account for Higgins.  

 

Update: Neil Macehiter adds some details.

  • Chuck's extension appears to require Firefox 2
  • XMLDAP requires Java 1.5
  • CardSpace on XP requires .NET Framework 3

  • #1 is the all Microsoft scenario
  • #2 ties Firefox into the Cardspace identity selector through the selector from Kevin Miller.
  • #3 ties Firefox into Cardspace through Kevin's plug-in, but allows for the scenario of a user choosing to use a different identity selector than Cardspace
  • #4 is Chuck Mortimer‘s Firefox plugin as an alternative identity selector to Cardspace.
  • #5 is a non-Cardspace identity selector for Safari.

 

HelloWorld Information Cards

One of the most important things about the Information Card paradigm is that the cards are just ways for the user to represent and employ digital identities (meaning sets of claims about a subject). 

The paradigm doesn't say anything about what those claims look like or how they are encoded.  Nor does it say anything about the cryptographic (or other) mechanisms used to validate the claims. 

You can really look at the InfoCard technology as just being

  1. a way that a relying party can ask for claims of “some kind”;
  2. a safe environment through which the user can understand what's happening; and
  3. the tubing through which a related payload is transfered from the user-approved identity provider to the relying party.  The goal is to satisfy the necessary claim requirements. 

If you have looked at other technologies for exchanging claims (they not called that, but are at heart the same thing), you will see this system disentangles the communication protocol, the trust framework and the payload formats, whereas previous systems conflated them.  Because there are now three independent axes, the trust frameworks and payloads can evolve without destabilizing anything.

CardSpace “comes with” a “simple self-asserted identity provider” that uses the SAML 1.1 token format.  But we just did that to “bootstrap” the system.  You could just as well send SAML 2.0 tokens through the tubing.  In fact, people who have followed the Laws of Identity and Identity Metasystem discussions know that the fifth law of identity refers to a pluralism of operators and technologies.  When speaking I've talked about why different underlying identity technologies make sense, and compared this pluralism to the plurality of transport mechanisms underlying TCP/IP.  I've spoken about the need to be “token agnostic” – and to be ready for new token formats that can use the same “tubing”.

There have been some who have rejected the open “meta” model in favor of just settling on tokens in the “concept de jour”.  They urge us to forget about all these subtleties and just adopt SAML, or PKI, or whatever else meets someone's use cases.  But the sudden rise of OpenID shows exactly why we need a token-agnostic system.  OpenID has great use cases that we should all recognize as important.  And because of the new metasystem architecture, OpenID payloads can be selected and conveyed safely through the Information Card mechanisms just as well as anything else.  To me it is amazing that the identity metasystem idea isn't more than a couple of years old and yet we already have an impressive new identity technology arising.  It provides an important example of why an elastic system like CardSpace is architecturally right. 

It's sometimes hard to explain how all this works under the hood.  So I've decided to give a tutorial about “HelloWorld” cards.  They don't follow any format previously known to man – or even woman.  They're just someting made up to show elasticity.  But I'm hoping that when you understand how the HelloWorld cards work, it will help you see the tremendous possibilities in the metasystem model.

The best way to follow this tutorial is to actually try things out.  If you want to participate, install CardSpace on XP or use Vista, download a HelloWorld Card and kick the tires.  (I'm checking now to see if other selector implementations will support this.  If not, I know that compatibility is certainly the intention on everyones’ part). 

The HelloWord card is just metadata for getting to a “helloworld” identity server.  In upcoming posts I'll explain how all this works in a way that I hope will make the technology very clear.  I'll also make the source code available.  An interesting note here:  the identity server is just a few hundred lines of code. 

To try it out, enter a login name and download a card (if you don't enter a name, you won't get an error message right now but the demonstration won't work later).  Once you have your card, click on the InfoCard icon here.  You'll see how the HelloWorld token is transferred to the relying party web site. 

This card uses passwords for authentication to the HelloWorld identity provider, and any password will do. 

Continue here…

Cool Tailrank page

I love Tailrank and its little pictures of blogs as this page on the CardSpace OpenID Collaboration Announcement shows.  I wonder how long the pages persist?  I'll have to remember to come back and look at this link in a couple of months.

Meanwhile, I thought I would explore Tailrank further and got to the part where I had to sign in and said to myself, “No, I don't have time for that”. 

Then it occured that this was just one more concrete example of a Web 2.0 opportunity going down the drain.

It seems so clear to me the Web 2.0 community should climb on board this user-centric identity thing ASAP. 

 

I-names and CardSpace

Here are some smart comments by =Andy.Dale of ooTao on how Information Card identity selectors like CardSpace and Higgins should work with XDI and i-names.  Andy has played an important role in introducing OpenID to ISPs and his comments bear directly on the convergence theme we've been discussing:

I wrote this missive in an email thread about using CardSpace with i-names I thought I should share it with you too:

IMHO the use cases that i-names support are a super set of the use cases that cardSpace supports… All of the digital identity usecases where someone else's wants to refer to me they need to use a globally unique identifier to identify me. Now I could keep giving people (services) my email but I'd much rather give my i-name. When a party has my i-name they can bootstrap ANY functionality that I provide. This is very different from cardSpace.

CardSpace is REALLY good at doing authentication (on Vista clients). Here's where I'm going to go out on that limb… I-names aren't bound to any specific authentication mechanism, they can be used in SAML they can be used in OpenID, but they can be used in any number of other schemes as well. A managed i-card with a signed assertion from the i-broker that this i-name has been validated as belonging to this card holder seems to me to be just as valid a mechanism to authenticate an i-name as any.

Use case:

I go to Evite (the i-name enabled Evite) and say I want to invite =joe to my party. NOTE: CardSpace has no mechanism for me to identify ‘Joe'; I HAVE to know a global identifier for him. Now Evite can look up =Joe's invitation SEP (could be his contact service, an email or other). Later =Joe wants to look at his invitation at Evite so he goes to the site and logs in with the convenence of the cardSpace paradigm. I don't think that using cardSpace authentication diminishes the value of the i-name in doing what it is good at doing.

So once cardSpace/higgins is broadly available we are going to need to define an attribute type so that an RP can ask for an i-name (or should it ask for an xri?). We are also going to have to provide the list of parties that should be trusted to assert i-name ownership (self asserted ‘this is my i-name’ should NOT be trusted); presumably XDI.org could publish that list.

So in summary… I think that people NEED i-names; they are just too useful in too many usecases. I DONT think that authentication mechanism is a good place to focus on the value of i-names, I would go as far as to say that this is one of the biggest mistakes that we in the i-name community have made. Once you have authenticated that the principle is the valid user of i-name that's where the value starts, not stops. So authenticate by whatever means the RP wants, and then look at all the cool services that can happen.

By the way, I've been using my =Kim.Cameron i-name for a couple of years now – ever since I started this blog.  It has been a life-saver.  It has been my email conduit to my readers and allowed me to interact personally with many people all over the world – without ONE piece of spam.  

So I would be a fool not to be a big supporter.  And more broadly, I'm a fan of =Drummond.Reed‘s thinking about identifiers.  He and his associates have thought more deeply about what identifiers need to be than anyone else in the world.

 

New InfoCard Profile documents available

Arun Nanda, Mike Jones, and others both at Microsoft and Ping have been working very hard for a long time now to make sure the profile we used to build our prototypes, and then our product, was being fully shared with everyone else who wanted to interoperate.  This has also involved an ongoing attempt to make sure the profile was clear enough to be useful.

Today I'm posting new versions that I think are a lot clearer (let me know!)  First, here is A Guide to Supporting Information Cards within Web Applications and Browsers as of the Information Card Profile V1.0.  I think anyone adding InfoCards to their site will find this document useful.

In addition I'm putting up two documents intended for people who really want to get into the details of how to implement the underlying toolkits and platforms.  Don't feel compelled to read them if you aren't doing this type of work!  They are part of the process of working with our colleagues in OSIS, Higgins, etc – those building Identity Selectors and the system software that powers managed card providers and claims transformers.  The papers will also be of interest to academics and people who really like to get way down into how things work.   You should begin with A Guide to Interoperating with the Infomation Card Profile V1.0.  I'll post the second document (the normative technical reference) in a couple of days.

I'm beginning by putting these docs up here so everyone in the identity community can get access to them ASAP.  Ultimately, they will appear in many other places, including MSDN.

 

Ping will show OpenID / CardSpace integration

According to this post, Ashish Jain at Ping has a new prototype of how CardSpace / OpenID integration will work in their evolving product.  It seems to be a continuation of the work they've already done with SAML / CardSpace integration – only now, the OpenID protocol has been added to the metasystem mix.

Come to think of it, isn't Dick Hardt's Whobar pretty close to having this capability as well?  So I think a number of us have wanted to integrate this work for some time, but recently it has become more obvious what the advantages are.

Anyway, if you haven't read Ashish's piece:

Kim posted a pretty good description of how CardSpace and OpenID can interact. This has been talked about for a while and Kim did a great job of describing it.

CardSpace OpenID Integration

In short, I agree. In fact, if you want to see a demo of what Kim describes, please stop by Ping Identity’s booth next week at the RSA Conference and you will get to see exactly that. An OpenID IdP Server that uses CardSpace for runtime authentication.

It’s not done by any means. There are still some unresolved items. For instance, If the user already has a profile registered with the OP, at runtime should the server use the persisted attributes or the claims as provided by the card? And the support for multiple cards. But you will get the idea.

I still have a few questions though. AFAIK OpenID Authentication 2.0 considers authentication out of scope.. So….to prevent phishing and to build user’s confidence, I can use CardSpace. Or anything on the likes of PassMark’s mutual auth. To provide more confidence to the RP, I can use OTP, device finger printing, biometric, certificates, KBA whatever. However there doesn’t seem to be the SAML AuthnContext equivalent to convey this to the RP. Therefore RP has no way to determine the type of OP authentication or if the authentication ever happened.

Even if there is way to communicate the authentication type, there is no trust or relationship between the OP and the RP. So….RP (who as a service provider has everything to loose) has no reason to believe that the OP isn’t lying and may have to employ their own safety measures.

I’m still coming up the curve so I may be wrong, but something seems missing. I’ll keep looking.

Ashish makes an interesting point about conveying the authentication type in the protocol.  I certainly agree with him.

I also like his question about trust.  It's one others have asked and which I scratched my head about at first.  So I'll put in my two cents worth.

In all identity protocols, you have an authority that makes claims about a subject, and the relying party decides whether or not to believe them.  As computer nerds we have called that “trust”, though in real business environments it's usually more a matter of reducing risk to the point that, on balance, it's better to do a transaction than not to do it.

But what is “the trust” (risk analysis) based on?  Usually on business relationships.  For example, we trust a bank to make assertions of various sorts.  And we trust a partner or customer to make other assertions.  So the trust is rooted in our experience – in a relationship.

This is where OpenID does something different: the authority is simply the behavior of the internet, and the trust only pertains to an identifier (one could layer other capabilities on top of this).

Basic Tenets

  1. Every person has a URL to which they lay claim.
  2. Every URL has an identity provider that “speaks for” it.

When I go to a relying party I tell it which URL I claim.  Then it sends me to the identity provider that speaks for that URL to get a token saying I really control it.

I give that token to the relying party, which then contacts the identity provider to verify the token is valid (the actual protocol includes optimizations).

To believe the claim, the Relying Party (RP) needs to trust that the URL has not been tampered with (an evil party could alter it to say an evil identity provider speaks for it).  The RP also has to believe it really contacted the URL when finding out who spoke for it (I could have been misdirected through a DNS attack).  And it needs to believe it really contacted the identity provider when getting token validation (again trusting DNS).  The last two issues can be mitigated by using https, but that complicates it, and even then, the system has different characteristics than one based on cryptographic tokens.

All in all, the closest analogy is to using an email address as an identifier by asking what email address you own, sending you the email, and getting you to click a link showing you own the email.  In this case the relying party depends on the underlying mail system, DNS, and all that.  OpenID replaces email with web URLs.  So it's a lot more direct.

Proving control 

How does an identity service know you really control some URL?  Many approaches are possible.  Let me give the example of Yahoo's system (it's not OpenID but uses the same general idea). You log into their identity provider and it gives you a key (a couple of lines or random gook).  You must then paste the key into your html page and press a button back at Yahoo.  This causes their system to open your page and see if the key is there. If so, the service deems that you own the URL.  Having done this you can get rid of the key and the Yahoo identity provider is willing to “speak for” your control of the URL.  The whole process just takes five minutes.

 

Drummond Reed on CardSpace and OpenID

Amongst other things, Drummond is CTO of Cordance and co-chair of the OASIS XRI and XDI Technical Committees.  He's playing an important role in getting new identity ideas into the Internet Service Provider world.  Here he responds to my first convergence post:

Earlier this month Kim Cameron starting blogging about some of the phishing concerns he’s had about OpenID that he and Mike Jones have shared with myself and other members of the OpenID community privately since Digital ID World last September. Given that anti-phishing protection is one of the greatest strengths of CardSpace, one of Kim’s and Mike’s suggestions has been for OpenID providers to start accepting CardSpace cards for customer authentication.

Today Kim blogged his proposed solution for integrating OpenID and InfoCard in detail. He does a wonderful job of it, making it very clear how using CardSpace and OpenID together can be a win/win for both. With Windows Vista shipping to consumers at the end of the month, and the CardSpace upgrade now available to XP users, this is a very practical solution to increasing OpenID security that I expect all XDI.org-accredited i-brokers (who all provide OpenID authentication service for i-name holders) to implement as soon as they can.

Kim closes his post by saying, “That said, I have another proposal [for integrating OpenID and CardSpace] as well.” That’s good, and I await it eagerly, because I too believe the integration can go much deeper, just as it can for OpenID and SAML. The heart of it is individuals and organizations being able to assert their own resolvable, privacy-protected digital identifiers. That’s the foundation of the OpenID framework, and the job for which we’ve been designing XRI i-names and i-numbers for the past five years. Microsoft’s current default CardSpace schema does not yet natively support XRIs as digital identifiers, but adding them could increase their power and utility and be another big step towards convergence on a unified Internet identity layer.

I'm going to clone myself so I can find more time to write up my second proposal.  Meanwhile, just a small clarification.  Drummond talks about the “default CardSpace schema”.  He's really talking about the “default Self-Issued Card schema.” 

CardSpace itself handles tokens of any type, containing claims of any type.  There are no limitations on your schema if you create a managed card.  I'll make that clearer in my next post. 

Further, we tried to keep the “bootstrap” Self-Issued Card provider down to a minimal set of initial schema choices – precisely to leave room for a managed card ecology.  But one of those initial claims is a URL…  I thought an i-name or i-numbers would be able to go there.  Is more needed?