A number of you have emailed me directly and some have commented publicly with some thoughtful insight and I thank you for that. Vittorio has written a very thoughtful and detailed response on his own blog [LINK].

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.

In Kim’s words[LINK]

"Those of us who work on or with identity systems need to obey the Laws of Identity."

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". And the Universe assures me in large part that gravity will be obeyed right? Well for the most part, but you get my point.

So rather than a recommendation around user control and consent; I would rather it be obeyed and enforced by the protocol. Here’s where things get tricky as we’re trying to implement an Identity Meta-System and today, as Vittorio says, I may have a "coconut token" and tomorrow I might have some other token format.

Will the paradigm of RST/RSTR exchange change? Probably no, or not much.

Is there any dependency between the RST and the RSTR today? This I was surprised to learn is a "No".

What I think would solve the issue in some small part is to tie the RST to the RSTR in such a way that the STS cannot possibly generate an RSTR that includes claims other than what the RST requested.

How to support user consent?

To have user consent, the user needs to see what’s being said about them. So again I think you need to tie the DisplayToken to the RST or RSTR somehow.

Now, what about privacy?

That’s a tricky one and likely not 100% solvable but the approach of masking out aspects of the data seems to be what most people (Matt Ellis) suggest when I ask this question.  I don’t think it scales.

Today we mask out credit card numbers, providing only the last 4 digits. In other scenarios we mask out social security numbers again with the last 4 digits. Nowadays the combination of birthdate, zip-code and Surname "marketers can uniquely identify almost the whole population" [LINK].

Will the Displaytoken mask out these values also? will we end up with a DisplayToken that looks like this:

First Name: ****cis
Last Name: *****han
Date of Birth: *1/*1/*2
Zip Code: ***69
Email: f*********@mail.com

Huh??? This could get confusing right? And does it work long-term? No. Even today, in many cases folks DON’T NEED your social security number, they only need the LAST FOUR DIGITS!!!

As EJNorman on Vittorio’s blog states; "The question is: why shouldn’t a user be able to inspect what’s being said about him and sent to a relying party to verify that it’s what was expected?"

I think this is at the crux of Law #1. Control and consent right? If a user can’t see what’s being said about them they just have to trust the IdP’s STS. Anytime you "trust" you give up "control", no?

It seems to me that if we are to ask users to "trust" the IdP then we are headed towards establishing a rating or assurance level around the notion of an Identity Provider. Just as not all STSs are IdPs and not all certificate authorities are high-assurance certificate authorities, not all IdPs will be well implemented, reputible or trust-worthy IdPs. The reasons for this are not all malicious as I earlier stated:

1. An STS may unwittingly pump in claims into an RSTR without looking at the RST.
2. As Vittorio points out; an STS may choose not to verify the credentials in the RST
3. Without authentication, an STS might just give out tokens to any RP on your behalf (chances are very low and this IdP would go out of business fast).

The possibility of these things happening is there as the protocol allows it.

Coders/developers on the front line take the path of least resistance almost ALWAYS. Code and ship. If there’s a way to implement something that’ll get the RST/RSTR exchange working with an RP and IdP that doesn’t enforce or prevent 1,2,3 as listed above then my fear is we will end up with IdPs out there that are not well implemented and as a user, we will have little to no way of detecting the good IdPs from the bad.

One way to work towards a solution is to have more heads looking at this across both the TECHNOLOGY (Ws-Trust/Ws-Fed etc.) as well as the HUMAN ASPECT (Identity Laws).

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.

I think I need to think about this some more…but I feel like I’m getting it.

1. Self-Issued Cards in which essentially you act as your own security token service and
2. Managed cards – in which a trusted third party acts as Identity Provider making assertions around your identity.

I have seen many examples leveraging self-issued cards but relatively few incorporating managed cards. There is a sample STS available on the http://cardspace.netfx3.com website but due to the complex nature of it I’ve found it challenging to set up and leverage. If you look at the message boards they are full of issues and questions involving managed cards.

To mitigate this I’ve put together a managed STS and will be hosting it here from my own website in the coming days. It’ll allow you to setup a relying party, setup claims and test values for same and even download a managed card.

I’ll also provide a generic test harness that’ll simulate your relying party and allow you to test the end to end interactions. Last thing it’ll do is provide you with the RST and RSTR structures passed around in XML as we go.

I hope this’ll be a useful service and a useful learning tool and there’ll be more to come on that in a few days. (as a side note I’m surprised Serrack or Microsoft hasn’t set this up themselves by now).

But of course there is a selfish agenda to all my work and the main reason I did this is because I wanted to understand the inner workings of a security token service. This (painful) process has shown me…

1. how it processes the Request for a Security Token
2. how it generates the Request for a Security Token Response
3. how the Cardspace Identity Selector will process that and lastly
4. how to consume the token on the Relying Party side.

When an RP indicates it needs a claim, let’s say
http://schemas.francisshanahan.com/sts/superclaim

Cardspace includes that as a required (or optional) claim in an RST. The Security Token Service reads this, (presumably) locates the value for this claim and then includes that value in an RSTR.

One thing I was surprised to learn is that Cardspace Identity Selector doesn’t actually display this value! The ID selector actually displays a value from what’s called a "Display token". Here’s where things begin to break down (for me)…

The values in the Display Token are actually what get displayed to the user.

So tying back to the Laws of Identity: The user should have knowledge and control over what gets sent to any Relying Party.

This Displaytoken seems to violate this as follows…

1. There is nothing that prevents the STS from including claims in the RSTR that were not requested in the RST.  Thus an STS could
   • ignore the "isOptional" attribute of each claim and include that information regardless.
   • Or worse still, an STS could include claim values that WERE NEVER requested. I’ve tried this with my own STS and Cardspace happily forwards these on to the RP for decryption.
2. There is nothing that prevents the STS from including Values in the Display Token that are DIFFERENT from the values in the actual claims token. So for example, it may be shown to the user that they are passing an email address of "foo@bar.com" but in reality the value being sent to the RP is actually "mypersonal@emailAddress.com". The user wouldn’t know at best until the RP processed the RSTR token.
3. Whilst the Security token is encrypted and bundled up nicely to protect its information, the DisplayToken is sent in clear (to allow the Cardspace selector to display it). Now what’s the point of protecting your claims in a security token if you go ahead and put those same claims in a Display token? How can we have user control and consent (Law #1) without violating the security of the data itself?

So it seems once again I have confounded myself with Identity by delving into the details. Perhaps it would be better to just go along with the whiteboard conversations and ws-trust what I’m being ws-told rather than ws-implement it?

It would appear based on my rudimentary investigations that there’s a potential for the first Law to be broken either through
a) Unwittingly implementing an STS that pumps in claims into an RSTR without looking at the RST.
b) A malicious STS mis-representing claims to a end user and secretly passing different information to an RP.

This for me was the kind of "Ahaah" moment that would typically not be uncovered until knee deep in an implementation and could potentially derail a project. I’m not saying this is the fault of  Cardspace, or even the Identity Meta-System. Rather I think this is a problem that’s just inherent with Law #1. As with anything I tend to find there is a lot of buzz around the high-level solution but sometimes when you dive a level deeper, you come to find out there may actually be a problem [LINK].

That’s why it’s always better to be an "I-know-it-works-because-I-tried-it,-look-my-hands-are-dirty" architect than an "I-don’t-know-what-the-problem-could-be,-it-compiled-on-the-whiteboard" architect.

I will talk to Kim[LINK] about this…

This is because CardSpace claims have recently been updated to use the xmlsoap.org namespace. Update any references you find to http://schemas.microsoft.com to http://schemas.xmlsoap.org for the fix.

Here’s what the updated FabrikamUP.ini file should look like:

-====================== CUT BELOW ===============================-
[CARD]
; type is one of UserNamePassword,KerberosAuth,SelfIssuedAuth,SmartCard,
TYPE=UserNamePassword

[Details]
Name=My Card (U/P backed)
ID=http://www.fabrikam.com/card/unpw/randomnnumber123
version=1
image=imagesfabrikam.jpg

[Issuer]
Name=Fabrikam Auto Group
Address=http://www.fabrikam.com:3074/sts
MexAddress=https://www.fabrikam.com:4074/sts/mex
PrivacyPolicy=http://www.fabrikam.com/PrivacyPolicy.xml
; certificate should be either a STORELOCATION/STORE/Subject name
; or
; c:pathtocert.pfx — in which case you also need a CertificatePassword=
Certificate=LOCALMACHINE/MY/www.fabrikam.com
;CertificatePassword=foo

[Claims]
; add claims required for card. standard (self issued) are listed below.
; keynames are not important (just don’t duplicate them)
1=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
2=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
3=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
;3=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress
;4=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality
;5=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince
;6=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode
;7=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country
;8=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone
;9=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone
;10=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone
;11=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth
;12=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender
;13=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
4=http://my-uri.com/test

[http://my-uri.com/test]
display=My Super Claim
description=A claim for all to see

[TokenTypes]
; add token types.
; keynames are not important (just don’t duplicate them)
1=urn:oasis:names:tc:SAML:1.0:assertion
;2=http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1

[Token Details]
RequiresAppliesTo=false

[Credentials]
; if the Auth type is UserNamePassword the value is the Username
; if the Auth type is SmartCard the value is the Certificate Path(Localmachine/my/www.fabrikam.com), hash, filename (in which case you may need certificatepassword=)
; if the Auth type is SelfIssuedAut the value is the PPID
value=FrankLee
Hint=Enter your username and password

-=================== CUT ABOVE =====================-

1) Enable SSL on your page – The Infocard ID selector only works for pages running under SSL. This means you need to purchase a certificate and install it on your web server. That’s easy. The hard part is figuring out how to create a test certificate for use on your personal web server. Turns out this is easy too. Download the "Internet Information Services (IIS) 6.0 Resource Kit Tools" HERE. Install it and then navigate to "C:Program FilesIIS ResourcesSelfSSL". Run "SelfSSL.exe" in that folder.

2) Install IE 7 – only IE 7 supports the Cardspace Info selector. Download IE 7 here.. There are some home-grown plugins you can find for FireFox but I will not focus on these for now.

3) Install the cert in your browser. Now you can launch your page under SSL using IE7. The browser bar at the top will turn pink as this site is running under a test certificate. If you try and launch the ID selector now you’ll get an error "An incoming identity could not be validated." The ID selector will then close. To fix this click "Certificates" button in the Browser Bar in IE 7. Click "View Certificates" then click "Install Certificate". Now you’ll be able to launch your ID selector.

4) The markup required on the page is just this:
<object type="application/x-informationCard" name="xmlToken">
   <param Name="tokenType" Value="urn:oasis:names:tc:SAML:1.0:assertion" />
   <param Name="requiredClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" />
</object>
Then submit the form like this:

<a href="javascript:void(0)" onclick="javascript:document.forms[0].submit()">Submit me</a>.

That’s it. You still need to parse the token (you can use the TokenHelper.cs Lab code for this). and so on but you now can launch the ID selector and have a nice test environment.

If you are trying to get the Infocard Labs working from the Vista Beta2 release of Infocard (earlier this year) with the latest June CTP of the .NET framework you’ll find the code doesn’t work with the latest CTP. This is due to a number of breaking changes that were implemented in the latest CTP.

You’ll find a list of these here: Breaking changes.

I found the most important one was the change from System.ServiceModel.Identity to System.ServiceModel.EndpointIdentity.

That should keep all four wheels on the road until the next CTP.