Category: Claims

Getting claims when using no-ssl CardSpace

When a user tells CardSpace to “send” identity data from a self-issued card to a web site,  it posts a SAML token using the action attribute in the HTML form containing an x-informationCard Object tag.

In the simple, no-ssl case, this information will not be encrypted, so you can just treat it as an XML blob.  You can test this out by making the form's action a script like this one:

This script just takes everything that is posted to the web server by CardSpace after processing the invocation form, and reflects it back as an “XML encoding”.  The result is shown in my demo, and in the no-ssl zip file as result.xml.

As pedagogical as the XML dump may be, it isn't a good sample of how you would consume claims.  For that, let's look at the following script:

GetClaims() shown above is just a way of pulling values out of an XML document – use your own instead.  You will see that the givenname and privatepersonalidentifier claims used here are retrieved with this simple code.

I hope all of this will become very clear by watching the demo and looking at the aforementioned zip file, which you can cut and paste for your own experiments.

[Note:  the raw XML display code above did not include the stripslashes function when I first posted it, which caused the function to fail in certain php configurations.  Thanks to Alex Fung from Hong Kong for the report.]

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.

HTML to invoke CardSpace on your site

In an upcoming post called Ultimate Simplicity: 30 lines of code, I show how to tweak a web page so it presents the option of logging in with an information card – without requiring you to dirty your hands with certificates.

If you haven't seen the demo yet, I start from a simple web page like this one:

I add an HTML form like this:

The form has an ID of “ctl00′, and a post action called “dump_input.php”.  In other words, when the form is submitted (by clicking on the icon specified in the “img” section) the contents will be posted and the script “dump_input.php” will be run on the web server.

The form contains an x-informationCard object tag, which takes a parameter of “RequiredClaims”.  This is followed by the claims the web page designer is asking for – in this case givenname and private personal identifier.

The zip of the sample code is here.

If you copy demo.html to your site, then when using the most recent release of CardSpace, you can navigate to that page, click on the icon, and you will be prompted for an infocard. 

The claims supported in CardSpace for simple self-issued cards are defined here – you could cut and past them into the “RequiredClaims” parameter of demo.php to alter the form's behavior.

Display Tokens in Information Cards

I recommend an interesting exchange between Citi's Francis Shanahan, Microsoft's Vittorio Bertocci, and University of Wisconsin's Eric Norman.  Here's the background.  Francis has spent a lot of time recently looking in depth at the way CardSpace uses WS-Trust, and even built a test harness that I will describe in another piece.  While doing this he found something he thought was surprising:  CardSpace doesn't show the user the actual binary token sent to a relying party – it shows a description crafted by the identity provider to best communicate with the user.

(The behavior of the system on this – and other – points is documented in a paper Mike Jones and I put together quite a while ago called “Design Rationale Behind the Identity Metasystem Architecture“.  There is a link to it in the WhitePapers section on my blog.)

Francis has his priorities straight, given the way he sees things:

I'm not sure how to solve this. I'm not sure if it's a fault inherent in the Identity Meta-system or if it's just a fact of life we have to live with.

I would never want to put the elegance of a meta-system design and accommodation of potential future token types ahead of supporting Law #1.

There is no question that elegance of design cannot be pitted against the Laws of Identity without causing the whole design to fail and any purported elegance to evaporate.

So clearly I think that the current design delivers the user control and consent mandated by the First Law of Identity. 

Let's start by seeing the constraints from a practical point of view.  In an auditing identity provider, one of the main characteristics of the system is that the provider knows the identity of the relying party.  Think of the consequences.  The identity provider is capable of opening a back channel to any relying party and telling it whatever it wants to.  In fact, from a purely technical point of view, the identity provider can just broadcast all the information it knows about you, me and all our activities to the entire world! 

We put trust in the identity provider when we provide it with information that we don't want universally known.  And more trust is involved when we accept “auditing mode”, in which the identity provider is able to help protect us by seeing the identity of the party we are connecting with (e.g. during a banking transaction).

Should we conclude the existence of scenarios requiring auditing mean the laws aren't “laws”?

“Going back to my original question which was “Does the DisplayToken violate the First Law of Identity?” I am not convinced it does. What I think I am discovering is that the First Law of Identity is not necessarily enforced.

“For me, being Irish Catholic (and riddled with guilt as a result) I take a very hard-line approach when you start talking about “Laws”. For example, I expect the Law of Gravity to be obeyed. I don't view it as a “Recommendation for the Correct Implementation of Gravity”…

The point here is that when the user employs an auditing identity provider, she should understand that's what she is doing. 

While we can't then prevent evil, we can detect and punish it.  The claims in the token are cryptographically bound to the claims in the display token.  The binding is auditable.  So policy enforcers can now audit that the human readable claims, and associated information policy, convey the nature of the underlying information transfer.  

This auditability means it is possible to determine if identity providers are abiding by the information policies they claim they are employing.  This provides a handle for enforcing and regulating the behavior of system participants.

We've spoken so far about “auditing” identity providers.  The system also supports “non-auditing” providers, who do not know the identity of the relying party.  In this case, a back channel is not possible.  The auditing of the accuracy of the display token is still possible however.

There is also an option for going even further, through the use of “minimal disclosure tokens”.  In such a system, the user can have an identity provider that she operates, and which submits her claims to a service for validation.  In this architecture, the user can really be guaranteed that there are no back channels or identity-provider injected goop.

Again, we are brought to understand that the identity metasystem spans a whole series of requirements, use cases and behaviors.  The most important thing is that it support all of them. 

I do not want a “non-auditing” bank account.  In that context, display tokens bound to information tokens and associated with an information policy all seem fine to me.

On the other hand, when browsing the web and doing many other types of transactions I want to prevent any identity provider from profiling me or obtaining any more information than necessary.  Minimal disclosure tokens are the best answer under those circumstances.

The uberpoint:  unless we have a system that embraces all these use cases, we break more than the first law.  We break the laws of minimal disclosure, necessary parties, identity beacons, polymorphism, human integration and consistent experience.   We need a balanced, pragmatic approach that builts transparency, privacy, user control and understanding into the system – integrated with a legal framework for the digital age.

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.

Business, Model, Scenario and Technology

Reading more of the discussion about Identity Oracles, I've come to agree with the importance of having separate names for the business model and the underlying technology that would be used to deliver services.  So I buy Dave Kearns's advice: 

Drop it while you can, Kim. Bob's right on this one. The “Identity Oracle” is a business model, not a technology feature.

Why was I conflating things?

Well, when we were devising the technology for claims transformers, we were specifically trying to enable the scenario of providing answers to questions without releasing the information on which the answers are based (in other words, support derived claims).  We intended the claims transformer to be the technology component that could supply such answers. 

I saw the name “Identity Oracle” as describing the scenario.

Now I see the advantages of having very precise naming for a number of interrelated things.  It can leave us with this taxonomy: 

Reading Dave Kearn's post on how a service like HealthVault might evolve in the direction of an Identity Oracle, I couldn't help wondering about the problems of liability implied by some of these behaviors.

For example, consider a health-related Identity Oracle that could answer the question, “Can Kim take drug X without fear of drug interactions?”.  The resultant “yes” or “no” would be a lot more privacy friendly than releasing all of Kim's drug prescriptions and the medical information necessary to adequately answer the question. 

However, the Identity Oracle presumably assumes more liability by “selling” its “yes” or “no” conclusion than it would by releasing simple facts (assuming the right permissions and use restrictions were in place). 

In other words, success of this model will involve a transfer of liability from the party currently making a decision to the oracle.  This liability has to be factored into the cost structure of the identity oracle business model, and the resultant pricing must make sense to the requesting party.

Bob Blakley on the Identity Oracle

As you can read here, Bob Blakley thrashes me for my characterization of an Identity Oracle as “his sexy name for the claims transformer generating “minimal disclosure tokens”.   He thinks I'm being geeky, and I probably am, but hey, geeks are people too.

He puts it this way:

 This statement is utterly and completely wrong.  An Identity Oracle is NOT a “claims transformer generating minimal disclosure tokens”.  It’s not even a claims transformer.  It’s not even a server.  It’s not even technology.

“It's not even technology.”  I guess it “just happens”.  Reminds me of how Bentley Motorcars describe what others would call a factory:

This isn’t a factory visit. It’s the Bentley Experience.

But let's not turn our backs on Bob's pain:

I’ve said twenty times from various stages and in writing on my personal blog and here that as long as we continue to try to solve privacy problems using technology, we are going to continue to fail, and the Internet will continue to lack an identity layer, and it will continue to be a privacy hazard.  Identity and privacy are not technology problems – they’re social, legal, and economic problems – and no technology can solve these problems.

Of course I agree that technology can't solve problems, only its design and usage can.  Although identity and privacy are social, legal and economic problems, they are technical ones too.

It's paradoxical that I have to be the person to suggest that The Burton Group take in a bit of lawyer Lawrence Lessig's thinking about these matters, nicely summarized here:

Lessig… addresses the two forms of code that dominate the Internet: legal code (law) and machine code (the technology supporting the Internet).  As Lessig points out, the influence of both must be understood, as both will determine the shape of the future.

That has become a bit of a mantra for me, and one of the reasons why, when I see interesting policy ideas, I try to understand how they relate to “code”.

Anyway, let's get to all the good points Bob makes.  Here's the basic dialog a service has with the Identity Oracle: Continue reading Bob Blakley on the Identity Oracle

MSN and Windows Live CardSpace Beta

You can now use Information Cards at Hotmail and all the other MSN/Windows Live sites. 

Just go here to associate an Information Card with your existing account.   I found that both Windows CardSpace and the Mac DigitalMe information card selectors worked beautifully with the system.  Check out this video to see what it was like registering and logging in from my Mac using DigitalMe. 

It's worth taking a step back to think about what can go wrong when you add a feature of this importance to a site with 300 million accounts.  If things don't work, you don't have a software bug – you have a trainwreck.  So the Windows Live people have done a lot of thinking, planning and testing in order both to create a cool experience and keep from confusing their users.   

There are still some anomolies.  In the words of the Beta announcement: Continue reading MSN and Windows Live CardSpace Beta

Guess what? Rabodeb is not his “real” name

A rivetting “natural” story of pseudonymity has risen to prime time in America's financial press – partly because government prosecutors have entered the fray. We're not talking here about a teenager, novelist, or garret inhabitant. This involves a corporate executive – John P. Mackey, co-founder of Whole Foods Market, who we have just found out goes by the name of “Rahodeb“. Continue reading Guess what? Rabodeb is not his “real” name

Long live minimal disclosure tokens!

Stefan Brands has a nice new piece called, Anonymous Credentials? No, Minimal Disclosure Certificates!  I think he's right about the need to stay away from the moniker “anonymous credentials”.  I adopted it – in spite of the confusion it creates – but I hereby give it up.  If I use it again, slap me around:

“Kim Cameron is in the midst of blogging an excellent series of posts on the important topic of unlinkability; see here and here, for instance. As I had expected from past experience, several commentors on Kim’s post (such as here and here) wrongly equate unlinkability with anonymity. Of course, an unfortunate choice of terminology (‘anonymous credentials’) does not help at all in this respect… 

“In short, ‘anonymous credentials’ are not all about anonymity. They are about the ability to disclose the absolute minimum that is required when presented an identity claim. Similarly, ‘unlinkability’, ‘untraceability’, and ‘selective disclosure’ are not about anonymity per se.

“Anonymity is just an extreme point on the privacy ‘spectrum’ that can be achieved, all depending on what attribute information is encoded in certificates and what of that is disclosed at presentation time. Currently prevalent technologies, such as standard digital signatures and PKI/X.509 certificates, are a poor technology to protect identity claims, since they inescapably leak a lot of identifying information when presenting protected identity claims; in particular, they disclose universally unique identifiers (correlation handles) that can be used to unambiguously link their presentation to their issuance.

I hope people will think hard about the difference between privacy and anonymity to which Stefan calls our attention.  Both are important, but people in the privacy community consider it crucial not to conflate them.  I'll try to find pointers to some of the detailed analysis that has been done by people like Simon Davies of Privacy International and Ann Cavoukian, Privacy Commisioner of Ontario, in this area – not to mention a host of other advocates and policy specialists.

So I'm going to STOP saying anonymous credentials, and even fix my very time-consuming graphic!  (Is that true dedication or what??) 

But I hope Stefan will allow me to say “Minimal Disclosure Tokens” rather than “Minimal Disclosure Certificates”.  I know the word “token” can possibly be confused with a hardware second factor, but its usage has become widely accepted in the world of web services and distributed computing.  Further, I want to get away from the connotations of X.509 “certificates” and forge new ground.  Finally, the word “tokens” ties in to thinking about claims, and allows us to envisage not only “hiding” as a means of minimization, but less draconian mechanisms as well.