Category: Information Cards

A C# Code Library for building an Information Card STS

I just heard about SharpSTS – a new open source project that allows you to implement a custom claims provider that will support Identity Selectors like CardSpace.  Better still, the code base has been posted.  Barry Dorrans, from idunno.org,  says:

Dominick and David beat me to the punch; last night I hit the “publish” button on codeplex for SharpSTS; a C# library to allow you to develop Information Card Security Token Services.

As with all open source projects there is still a bunch of work to do; as it stands we have a command line STS which should allow you to get started. Well; if you can work out from the source code what you need to do 🙂

Over the coming weeks and months I, as dictator, Dominick Baier and David  Christiansen hope to deliver a stable, tested, code base from which you can deliver managed information cards to your users, as well as a test web site which will issue and accept managed cards.

In the mean time you can download the code, implement your own authorisation policy provider and get started. In the meantime we’re guiding the rough beast, its hour come round at least, slouching towards Redmond to be born (with apologies to Yeats).

Wow.  Not only an STS but Yeats too!

SharpSTS is a C# code library which enables easy development of a Security Token Service, the server component for managed Information Cards.

To begin developing with SharpSTS you will need Visual Studio 2008 Standard (or higher), an SSL certificate and a client system that supports Information Cards.

The source code is available from http://www.codeplex.com/sharpSTS and is licensed under the Microsoft Public License (MS-Pl).

For those who are curious, the SharpSTS site includes a notice making it clear that “this web site, service and code are unaffiliated with Microsoft…”.

Handbags at dawn?

Here is Pat Patterson's post on my recent discussion with Ben Laurie.   Pat is a widely respected member of Sun's identity team, blogs at Superpatterns, and runs the useful PlanetIdentity RSS feed.   There are a number of ways you could build a Password Manager for CardSpace, but I thought readers would enjoy seeing Pat's take on it:

You might have noticed the exchange between Ben and Kim over the past day or two… Ben made a point that CardSpace makes OpenID redundant – why not just send a password to the RP? Kim jumped all over him – somewhat misinterpreting what Ben later describes as one of my most diabolical hungover bits of prose ever. Ben goes on to clarify that maybe CardSpace can have a role in helping the user manage passwords; Kim says “Hmm… Food for thought” (okay, I'm paraphrasing); Ben admits he didn't explain himself too clearly to begin with; and, glory be, they're violently agreeing. Phew! I thought we were going to be seeing handbags at dawn…

Reading all this lit a spark in my mind of how this could work. The crux is to consider the username/password token, usually sent as one of a set of possible input tokens to an identity provider security token service (IP/STS), as an output token.

Here's how it would work… Borrowing a diagram from Microsoft's Guide to Interoperating with the Information Card Profile V1.0:

First of all, the IP/STS would specify ic:RequireAppliesTo in the managed card. This tells the identity selector to include a wsp:AppliesTo element in the wst:RequestSecurityToken (RST). The IP/STS is going to need this later…

Now, the user visits the relying party (RP) in step 1, requesting some resource. In step 2, the ‘service requestor’ (application client with identity selector) requests security policy from the RP. The RP would indicate, in step 3, that it wanted a username/password token by specifying a token type of http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0 in the policy.

Now the identity selector presents some set of information cards (hopefully just one) to the user (step 5) and the user selects one (step 6). Steps 7 and 8 would see the RP requesting security policy from the IP/STS, and the IP/STS supplying it, exactly as in the standard information card interaction. Here the IP/STS could require any form of input token, but username/password is most likely.

Between steps 8 and 9, the identity selector prompts the user for credentials (bad Microsoft, missing that out of the diagram!) and in step 8, the identity selector packages up the user's credentials in a WS-Trust RST and send them to the IP/STS.

Now, here's the interesting bit. The IP/STS authenticates the user, exactly as in the standard CardSpace case, but now it looks at the wsp:AppliesTo element, and looks up the user's username/password pair for that RP (this is an implementation detail – there could be a mapping of RP identifiers to username/password pairs per user, all encrypted on disk, of course). The IP/STS packages them as a wsse:UsernameToken, which is then encrypted with the RP's public key and returned to the identity selector (step 10). The display token could just show ******** for the value of the password claim. Now we have a nice, securely packaged credential that the identity selector can send to the RP in step 11.

Here's the other nice bit… All the RP has to do is to decrypt the incoming token and it has the user's username and password, exactly as if they had arrived by a conventional form post. No further customization required at the RP – no changes to directory or database schemas, no extra steps of associating an information card with your account. Passwords on steroids.

If the RP uses https, I'm not even sure there is any need to decrypt at the token layer, which simplifies implementation to decoding a simple xml structure.  RP's who are looking for greated levels of security should switch to public key.

I'd like to hear Pat's ideas about the user experience of bootstrapping the passwords into the Identity Provider.

From “Screen-Names in Bondage” to OpenID

Google's Ben Laurie proposes using “functions of passwords” rather than plain passwords as a way to avoid phishing: 

Kim Cameron writes about fixing OpenID’s phishing problems by using Cardspace. Certainly I agree that using strong authentication to the OpenID provider fixes the phishing problem – but if you have strong authentication, why bother to use OpenID at all? Why not strongly authenticate to the site you are really trying to log into, instead?

Of course, Cardspace is a pretty heavyweight solution for this, so perhaps that’s what Kim’s getting at? It also doesn’t work well if you have more than one machine – moving your credentials around is not something Cardspace does well.

In my view, there’s a sweeter spot for solving this problem than Cardspace (or OpenID, obviously) – and that is to do strong authentication based purely on a password. That way, you can use the same password everywhere, so no problem with moving between machines, but can still resist phishing attacks and don’t have to make yourself linkable across all sites. Obviously supporting this would be way easier than taking the whole of Cardspace on board, but would have all of the immediate advantages. Clearly it would get you nowhere with advanced identity management, but its not like we don’t already have protocols for that and nor does there seem to be much demand for it yet.

I take it Ben is talking about having a toolbar that asks for your password, and transforms it based on the site's identity so you can use the same password everywhere.  Perhaps he is even thinking about a digest protocol where this transformed password would be used to calculate a “proof” rather than transported over the wire.

Phished or Pharmed 

Problem is, such a toolbar is as easily “pharmable” as OpenID is phishable.

How does a user know she is typing her password into the legitimate toolbar – rather than an “evil replica”?  Our experience with toolbars teaches us that is easy to trick a LOT of people into using fakes.  In fact, sometimes the fakes have propagated faster than the real thing!  Once people get used to typing passwords into a toolbar you have truly opened Pandora's Box.

Let's look at what happens when the kind of “common password” Ben proposes is stolen. In fact, let's compare it to having money stolen. 

If you go into a store and are short-changed, you just lose money in one store.  If you are pick pocketed, you just lose what's in your wallet – you can cancel your cards.  But if your “common password” is intercepted, it is as though you have lost money in ALL the stores you have been in.   And sadly, you will have lost a lot more than money.

The ultimate advantage of moving beyond passwords is that there is then NO WAY a user can inadvertantly give them away.

Is CardSpace too heavy-weight? 

CardSpace should be a lighter-weight experience than it is today.  We're working on that, making it less “in-your-face” while actually increasing its safety.  I also agree with Ben that it needs to be easier to roam credentials.  We're working on that too. 

The point is, let's evolve CardSpace – and the interoperable software being developed by others – to whatever is needed to really solve the relevant privacy and security problems, rather than introducing more half-measures that won't be effective.

So why OpenID?

If that's all true, Ben wonders why we bother with OpenID at all…

The most important reason is that OpenID gives us common identifiers for public personas that we can use across multiple web sites – and a way to prove that we really own them.

That is huge.  Gigantic.  Compare it to the cacophony of “screen-names” we have today – screen-names in bondage, prisoners of each site.

Technology people are sometimes insulted when you imply they haven't solved the world's problems.  But to be really important, OpenID doesn't have to solve the world's problems.  It just has to do this one common-identifier thing really well.  And it does.  That's what I love about it.

CardSpace doesn't address the same problem.  CardSpace plus OpenID solve it together. 

xmldap / openinfocard paymentCards

Axel Nennker from ignisvulpis has been enhancing the openinfocard identity selector – I'm hoping to catch up with him soon and learn more about where the project is headed.  Meanwhile this post is very interesting:

At DIDW 2007 I heard Sid Sidner talk about variable claims and how they could be used for online payment. Kim Cameron, who sat next to me during Sid's talk, suggested that I should include this into the openinfocard id selector. Today I uploaded two new applications to xmldap.org. You can use the STS to create a paymentCard and import it into the openinfocard id selector:

Next go to the paymentCard relying party. You can change the price to see that the claim can be changed by the merchant. Type a new price into the input field and press enter. Next click on the paymentCard icon to start the openinfocard id selector:

 

 Select a paymentCard using the openinfocard id selector:

 

 The result looks something like this:

 

Please note the “trandata?” claim. This is the one that is modifiable by the relying party. It can contain anything. Sid suggested to base64 encode the data needed for 3D-secure. I just use the variable claim to transport price information from the merchant to the STS. The basic principle: If a claim contains a ‘?’ then the matching of the claim against the claims in a information card stops; that is the claim “matches” and the whole claim is send to the STS in the RST. Of course this does not work with the current version of CardSpace. Some newer version of the openinfocard id selector should do it. This functionality is inside it since end of October (I think). I did not find time to blog about this feature earlier. Have fun.

I tried importing the card into CardSpace, but wasn't able to do so since the openinfocard STS currently issues the card using an expired certificate.  CardSpace checks for this, and other identity selectors should too.  Is this one of the tests in the emerging information card interoperability test suite? 

I'll pick this up again once the certificate problem is fixed.  Until then, it works very nicely with the openinfocard selector.

draft.blogger.com betas OpenID for blogger

Blogger.com now supports OpenID on its beta site.  I have to congratulate the blogger.com team on the user experience they've created.  This is not necessarily their final kick-at-the-can, but I like what they've done so far.

Blog owners have a simple radio-button selection to determine who can comment: 

 

From then on, when someone visits the blog as a user and wants to make a comment, they are given the choice of how to identify themself.  Choose “Any OpenID” and you are given the chance to enter one.  Click on that, and you are redirected to your OpenID provider.

Here's what it looked like for me.  I wanted to congratulate the team for their great work, so I filled out a comment form like this:

 

Then I pressed “Publish Your Comment” and got this:

That's because I use myopenid.com, which for me is phishproof because of its great Information Card support (in other words, no password is involved and no credential can be stolen).

That's it folks.  I pressed send and got:

Why is this implementation so good?  Because it doesn't torment you, doesn't make you set up an account, doesn't make you create a password you don't need, and doesn't nag you to join Blogger when that isn't in the cards.  And it puts full control over the kinds of credentials to accept into the hands of the bloggers  themselves. 

This is the kind of experience I have envisaged and have been waiting for.  I think it is a sign of things to come, since many other sites are looking at the same concepts.  There is going to be a “conflagration” when people start to “get it”.  Just look at the comments.  There could be a lot of people who do join Blogger just because they've been handed a carrot, not given the stick.

One last aside on the low-friction thing.  Once I've gone through the dance above, I can continue to post at Blogger.com and all other sites with which I've established relationships – without further authentication.   That is very powerful.

CardSpace for the rest of us

I've been a Jon Udell fan for so long that I can't even admit to myself just how long it is!  So I'll avoid that calculation and just say I'm really delighted to see the CardSpace team get kudos for its long-tail (no-ssl) work in Jon's recent CardSpace for the rest of us: 

Hat tip to the CardSpace team for enabling “long tail” use of Information Card technology by lots of folks who are (understandably) daunted by the prospect of installing SSL certificates onto web servers. Kim Cameron’s screencast walks through the scenario in PHP, but anyone who can parse a bit of XML in any language will be able to follow along. The demo shows how to create a simple http: (not https:) web page that invokes an identity selector, and then parses out and reports the attributes sent by the client.

As Kim points out this is advisable only in low-value scenarios where an unencrypted exchange may be deemed acceptable. But when you count blogs, and other kinds of lightweight or ad-hoc services, there are a lot of those scenarios.

Kim adds the following key point:

Students and others who want to see the basic ideas of the Metasystem can therefore get into the game more easily, and upgrade to certificates once they’ve mastered the basics.

Exactly. Understanding the logistics of SSL is unrelated to understanding how identity claims can be represented and exchanged. Separating those concerns is a great way to grow the latter understanding.

I've never been able to put it this well, even though it's just what I was trying to do.  Jon really nails it.  I guess that's why he's such a good writer while I have to content myself with being an architect.

Ultimate simplicity: 30 lines of code

With the latest CardSpace bits anyone who is handy with HTML and PHP, Ruby, C#, Python or almost any other language can set up CardSpace on their site in minutes – without the pain and expense of installing a certificate.  They can do this without using any of the special libraries necessary to support high security Information Card exchanges.

This approach is only advisable for personal sites like blogs – but of course, there are millions of blogs being born every second, or… something like that.  Students and others who want to see the basic ideas of the Metasystem can therefore get into the game more easily, and upgrade to certificates once they've mastered the basics.

I've put together a demo of everything it takes to be successful (assuming you have the right software installed, as described later in this piece).

From the high security end of the spectrum to the long tail

Given the time pressures of shipping Vista, those of us working on CardSpace had to prioritize (i.e. cut) our features in order to get everything tested and out the door on schedule.  One assumption we decided to make for V1.0 was that every site would have an X.509 certificate.  We wanted our design to start from the high end of the security spectrum so the fundamental security architecture would be right.  Our thinking was that if we could get these cases working, enabling the “long tail” of sites that don't have certificates would be possible too.

Let's face it.  Getting a certificate, setting up a dedicated external IP address, and configuring your web server to use https is non-trivial for the average person.  Nor does it make much sense to require certificates for personal web sites with no actual monetary or hacker value.  I would even say that without proper security analysis, vetting of software and rigorous operating procedures, SSL isn't even likey to offer much protection against common attacks.  We need to evolve our whole digital framework towards better security practices, not just mandate certificates and think we're done.

So again, when all is said and done, it is best to promote an inclusive Identity Metasystem embracing the full range of identity scenarios – including support for the “long tail” of personal and non-commercial sites.  One way to do this is through OpenID support.  But in addition, we have extended CardSpace to work with sites that don't have a certificate.

The user experience makes the difference clear – we are careful to clearly point out that the exchange of identity is not encrypted. 

Warnings are presented in words and graphics

In spite of this, CardSpace continues to provide significant protection against attack when compared with current browsers.  You are shown the DNS name of the site you are visiting as part of the CardSpace ceremony, not on some random screen under the control (or manipulation) of a potentially evil party.  And if you have been redirected to a “look-alike” site containing an unknown DNS name, you will get the “Introductory” ceremony rather than the more streamlined “Known site” ceremony.  This unexpected behavior has been shown to make people much more careful about what is appearing on their screen.  Ruchi from the CardSpace blog has a great discussion of all the potential issues here.

What software is required? 

As my little demo shows, if you have a website to which you want to add CardSpace support, all you need to do is add an “object tag” to your login page and parse a bit of xml when you get the Information Card posted back to your site.

On the “client” side, if you are using IE, first you will need to install an updated browser specific extension that will work at a non-SSL site.  If you have IE7 you probably already have it as part of the October security update.  If not, download it from here.

Second you will need to install an updated version of Cardspace that does the right thing when a website (we call it the “relying party”) does not have a certificate.  The latest version of Cardspace can be downloaded as part of .Net Framework 3.5 from here.

For people using Mac and Linux clients, I look forward to the upcoming Internet Identity Workshop as an opportunity to catch up with my friends from Bandit, OpenInfoCard, Higgins and others about open source support for the same functionality.  I'll pass on any information I can at that time.

Once you watch the demo, more information is available here and here and here.  The code snippets shown are here.

Download cheap oem discount software.

Claims in the self-issued Information Cards profile

This list of claims is taken from the Identity Selector Interoperability Profile, and specifies a set of claim (attribute) types and the corresponding URIs defined for some commonly used personal information…

The base XML namespace URI that is used by the claim types defined here is as follows: http://schemas.xmlsoap.org/ws/2005/05/identity/claims

For convenience, an XML Schema for the claim types defined here can be found here. 

8.5.1. First Name

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

Type: xs:string

Definition: (givenName in RFC 2256) Preferred name or first name of a subject. According to RFC 2256: “This attribute is used to hold the part of a person's name which is not their surname nor middle name.”

8.5.2. Last Name

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Type: xs:string

Definition: (sn in RFC 2256) Surname or family name of a subject. According to RFC 2256: “This is the X.500 surname attribute which contains the family name of a person.”

8.5.3. Email Address

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Type: xs:string

Definition: (mail in inetOrgPerson) Preferred address for the “To:” field of email to be sent to the subject, usually of the form @. According to inetOrgPerson using RFC 1274: “This attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822.”

8.5.4. Street Address

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress

Type: xs:string

Definition: (street in RFC 2256) Street address component of a subject?s address information. According to RFC 2256: “This attribute contains the physical address of the object to which the entry corresponds, such as an address for package delivery.” Its content is arbitrary, but typically given as a PO Box number or apartment/house number followed by a street name, e.g. 303 Mulberry St.

8.5.5. Locality Name or City

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality

Type: xs:string

Definition: (l in RFC 2256) Locality component of a subject?s address information. According to RFC 2256: “This attribute contains the name of a locality, such as a city, county or other geographic region.” e.g. Redmond.

8.5.6. State or Province

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince

Type: xs:string

Definition: (st in RFC 2256) Abbreviation for state or province name of a subject?s address information. According to RFC 2256: “This attribute contains the full name of a state or province. The values should be coordinated on a national level and if well-known shortcuts exist – like the two-letter state abbreviations in the US – these abbreviations are preferred over longer full names.” e.g. WA.

8.5.7. Postal Code

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode

Type: xs:string

Definition: (postalCode in X.500) Postal code or zip code component of a subject?s address information. According to X.500(2001): “The postal code attribute type specifies the postal code of the named object. If this attribute value is present, it will be part of the object's postal address – zip code in USA, postal code for other countries.”

8.5.8. Country

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country

Type: xs:string

Definition: (c in RFC 2256) Country of a subject. According to RFC 2256: “This attribute contains a two-letter ISO 3166 country code.”

8.5.9. Primary or Home Telephone Number

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone

Type: xs:string

Definition: (homePhone in inetOrgPerson) Primary or home telephone number of a subject. According to inetOrgPerson using RFC 1274: “This attribute type specifies a home telephone number associated with a person.” Attribute values should follow the agreed format for international telephone numbers, e.g. +44 71 123 4567.

8.5.10. Secondary or Work Telephone Number

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone

Type: xs:string

Definition: (telephoneNumber in X.500 Person) Secondary or work telephone number of a subject. According to X.500(2001): “This attribute type specifies an office/campus telephone number associated with a person.” Attribute values should follow the agreed format for international telephone numbers, e.g. +44 71 123 4567.

8.5.11. Mobile Telephone Number

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone

Type: xs:string

Definition: (mobile in inetOrgPerson) Mobile telephone number of a subject. According to inetOrgPerson using RFC 1274: “This attribute type specifies a mobile telephone number associated with a person.” Attribute values should follow the agreed format for international telephone numbers, e.g. +44 71 123 4567.

8.5.12. Date of Birth

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth

Type: xs:date

Definition: The date of birth of a subject in a form allowed by the xs:date data type.

8.5.13. Gender

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender Type: xs:token

Definition: Gender of a subject that can have any of these exact string values –

  • 0 (meaning unspecified),
  • 1 (meaning Male) or
  • 2 (meaning Female). Using these values allows them to be language neutral.

8.5.14. Private Personal Identifier

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier

Type: xs:base64binary

Definition: A private personal identifier (PPID) that identifies the subject to a relying party. The word “private” is used in the sense that the subject identifier is specific to a given relying party and hence private to that relying party. A subject?s PPID at one relying party cannot be correlated with the subject?s PPID at another relying party…

 8.5.15. Web Page

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/webpage

Type: xs:string

Definition: The Web page of a subject expressed as a URL.

Feeling fragmented?

Here is one of the best comments on digital identity I have ever seen.  Francis Shannahan makes it crystal clear how overly fragmented our online identities really are.  But he also shows perfectly that it would make no sense to try to compress all aspects of ourselves into a single context.  This is exactly the contradiction the Identity Metasystem is intended to resolve.

I love the diagram because it is so concrete – click on it to make it readable.  At the same time, it avoids over-simplification.  Francis has captured a lot about the yin and yang of identity, and I hope this diagram becomes an emblem for us.

“A few weeks ago I joined Facebook (after much resistence). Facebook sucks you in, making it so easy to give up bits of information about yourself, many times without even realizing it. It occurred to me that I'm leaving pieces of my identity everywhere.

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

Continue reading Feeling fragmented?

Assurance about what?

I'm facinated by this post by Pamela Dingle at Adventures of an Eternal Optimist:

Paul and Gerry have been talking about levels of assurance for self-asserted vs. managed cards, loosely based on my Let’s talk Turkey entry from awhile back. Paul calls Gerry’s stance hard-line; I’m inclined to agree.

Gerry states:

… as far as the Windows CardSpace identity system is concerned, there are indeed multiple levels of assurance for the RP:

  1. No assurance – self-managed cards, or any managed card where the Issuer is not enforced by the RP
  2. Assurance – managed cards where a particular set of Issuer(s) is required by the R[P]

Gerry also states that it’s ok to have no assurance for “low-value transactions”. This seems like a very strange statement to me. Whether you are a blog or a bank, you still want to have confidence that the the card and the data in it is correctly associated with the right account. Perhaps the bank cares more about the veracity of additional claims — but in my mind, any additional level of confidence in quality of data must first be based on a foundation of accurate identification.

Such thoughts led me to ask & try to answer the following question: Should an RP feel more confident in receiving a managed card from a user compared to a self-issued card?

For the purposes of token validation, the only thing I as an RP get in a managed card that I don’t get in a self-issued card (that I can think of anyway) is a certificate that is chained to a “trusted root certification authority”. This, of course, only gives me more actual assurance if I go to the trouble of verifying that the cert does indeed chain properly, and that it hasn’t been revoked.

As far as data veracity goes — well that has nothing whatsoever to do with the card format. It just as equally easy and possible to lie through a managed card as it is to lie through a self-issued card. The format guarantees nothing. Trusting a managed card because it is a managed card over a self-issued card is the equivalent of trusting hearsay over perjury.

A card issuer that simply parrots back what a user types into it will have certain uses, regardless of the issuing mechanism. A card issuer that adds value to what the user supplies will gain over time a different kind of reputation, and therefore will inspire a different level of confidence in both users and relying parties. Mistakes, abuse, quality of user experience, extra features – all of these things will play into trust decisions for transactions of all kinds, and of all values.  Dividing things into low-value vs. high-value classifications seem like a good way to divide things – but not with respect to identification mechanism. Think of the gmail user who becomes a Google payment user. A relying party in a high-value payment transaction involving a Google user still has to depend on the same identification mechanism used for a low-value google mail transaction. The foundations are the same – it has to work and it has to have some kind of assurance attached, for relying parties and users too.

I would put it this way.

  • Self-issued cards provide high assurance that the subject possesses the key associated with the card.  In other words, the key is itself a claim, and self-issued cards  intrinsically offer high assurance of the validity of this claim.  This may not sound big, but it's a big deal, since it is the essence of interactive authentication.  However, other self-asserted claims require out-of-band verification if certaintly is required.
  • Managed cards can provide various degrees of assurance around a broad set of claims.   In this case, an out-of-band process is required to establish what claims should be accepted from a given identity provider.

Sorry.  As Pam says, assurance isn't binary.