1. Achtergrond en implementatie van een identity metasystem
Windows Cardspace
Achtergrond en implementatie van een identity metasystem
Sander Gerz

2. Agenda
Identity Crisis
The Identity Metasystem
Windows CardSpace
Code

3. The Identity Crisis
The Internet was built without a way to know who and what you are connecting to
Internet services have one-off “workarounds”
Inadvertently taught people to be phished
Greater use and greater value attract professional international criminal fringe
Exploit weaknesses in patchwork
Phishing and pharming

4. Online Identity at Risk
Source:

5. Do we trust the Internet?
A majority of users (53 percent) say they have stopped giving out personal information on the Internet.
30 percent say they have reduced their overall use of the Internet.
Source: Consumer Reports, October 2005

6. Why? Users are confused, not in control
How to tell if the site is who it pretends to be?
Forms based authentication UI overload
Password Fatigue
Multiple Identity Management solutions
Largely incompatible
Inconsistent levels of security assurances
No way to transfer natural roles & responsibilities
Missing an “Identity layer”
No simplistic solution is realistic

7. Lessons from Passport designed to solve two problems
Identity provider for MSN
300M+ users, 1 billion logons per day
Identity provider for the Internet
Unsuccessful
Learning: solution must be different than Passport

8. What is a Digital Identity?
Set of claims one subject makes about another
Many identities for many uses
Required for transactions in real world and online
Model on which all modern access technology is based
Now we describe each of the metasystem components…
Subject is a person or thing represented the digital realm which is being described
A claim is an assertion of the truth of something (eg. I am over 21, I have access to this file, I am a US resident, I work for Microsoft)
Claims are packaged in a security token which normally travels over process and machine boundaries
Key point: Each of us has many identities (or “personas”) depending on the context e.g.
Bank card at ATM
Passport at border check
Coffee card at coffee stand (note this identity is anonymous – it’s possession that counts. identity <> knowing who you are)
MSN Passport (LiveId) at Hotmail
These IDs are easily out of context:
Passport at ATM
SSN as Student ID
MSN Passport at eBay
Coffee card at border check!
We need to recognize that digital identities are the same: we need many of them for different contexts. As simple as life would be with just one identity, in reality we need different identities from different providers and identity management involves context switching and maintaining multiple personas for the different relationships we have

9. “The Laws of Identity” User control and consent
Minimal disclosure for a defined use
Justifiable parties
Directional identity
Pluralism of operators and technologies
Human integration
Consistent experience across contexts
1. User Control and Consent
Technical identity systems must only reveal information identifying a user with the user’s consent.
2. Minimal Disclosure for a Constrained Use
The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.
3. Justifiable Parties
Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
4. Directed Identity
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.
5. Pluralism of Operators and Technologies
A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
6. Human Integration
The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
7. Consistent Experience Across Contexts
The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
To explain this slide well (i.e. take minimal time and give good examples) read
Directional identity: two types omni-directional (broadcast cf. my name in phone book, a company website) and uni-directional (point-to-point: communicating my health details to my doctor). CardSpace v1.0 addresses the uni-directional identity
Pluralism is the great lesson of the Internet
Human integration = computer system is fallible if don’t secure last 2 ft between screen and user’s brain
Consistent experience = even with multiple operators, technologies and scenarios we must have a consistent UX.
Counterexamples
Minimal disclosure = use of SSN for general identities at US universities
Justifiable parties = Microsoft with Passport when I’m using my bank or heath provider website
Directional = RFID in passports -> if omni-directional then can making a bomb detecting US citizens within 20 ft

10. Identity Metasystem We need a unifying “Identity Metasystem”
Welcomes multiple operators, technologies, and implementations.
Isolates applications from the complexities of identity management
Not first time we’ve seen this in computing
Emergence of TCP/IP unified Ethernet, Token Ring, Frame Relay, X.25, even the not-yet-invented wireless protocols
Solution to all computing problems: “Add a level of indirection and a good UI” !
Allow digital identity to be loosely coupled: multiple operators, technologies, and implementations
Not first time we’ve seen this in computing
> Emergence of TCP/IP unified Ethernet, Token Ring, Frame Relay, X.25, even the not-yet-invented wireless protocols
The picture is of Doc Searls, editor of Linux Journal: the Identity Metasystem has credibility and buy-in across the whole industry.
What is the Identity Metasystem?
Given that universal adoption of a single digital identity system or technology is unlikely ever to occur, a successful and widely employed identity solution for the Internet requires a different approach? One with the capability to connect existing and future identity systems into an identity metasystem. This metasystem, or system of systems, would leverage the strengths of its constituent identity systems, provide interoperability between them, and enable creation of a consistent and straightforward user interface to them all. The resulting improvements in cyberspace would benefit everyone, making the Internet a safer place with the potential to boost e-commerce, combat phishing, and solve other digital identity challenges.
In the offline world, people carry multiple forms of identification in their wallets, such as driver's licenses or other government-issued identity cards, credit cards, and affinity cards such as frequent flyer cards. People control which card to use and how much information to reveal in any given situation.
Similarly, the identity metasystem makes it easier for users to stay safe and in control when accessing resources on the Internet. It lets users select from among a portfolio of their digital identities and use them at Internet services of their choice where they are accepted. The metasystem enables identities provided by one identity system technology to be used within systems based on different technologies, provided an intermediary exists that understands both technologies and is willing and trusted to do the needed translations.
It's important to note that the identity metasystem does not compete with or replace the identity systems it connects. Rather, it plays a role analogous to that of the Internet Protocol (IP) in the realm of networking. In the 1970s and early 1980s, before the invention of IP, distributed applications were forced to have direct knowledge of the network link, be it Ethernet, Token Ring, ArcNet, X.25, or Frame Relay. But IP changed the landscape by offering a technology-independent metasystem that insulated applications from the intricacies of individual network technologies, providing seamless interconnectivity and a platform for including not-yet-invented networks (such as wireless) into the network metasystem.
In the same way, the goals of the identity metasystem are to connect individual identity systems, allowing seamless interoperation between them, to provide applications with a technology-independent representation of identities, and to provide a better, more consistent user experience with all of them. Far from competing with or replacing the identity systems it connects, the metasystem relies on the individual systems to do its work!

11. Actors Identity Provider Claims Encapsulation Negotiation Subject
Issues Identities
Claims
Age, Name, SSN
Employer, Gender. …
Encapsulation
Negotiation
Subject
Individual about whom claims are made
Relying Party
Requires Identities

12. Windows Cardspace Overview
Simple user visualization for digital identity
For managing collections of claims
For managing keys for sign-in and other uses
Grounded in real-world metaphor of physical cards
Government ID card, driver’s license, credit card, membership card, etc…
Self-issued cards signed by user
Managed cards signed by external authority
Shipping in .NET Framework 3.0
Runs on Windows Vista, XP, and Server 2003
Implemented as protected subsystem

13. Identity Provider (IP)
Protocol 7
User approves release of token
User
Client 1
Client wants to access a resource 4
User selects an IP
Request security token 5 3
Which IPs can satisfy requirements? 2
RP provides identity requirements 6
Return security token based
on RP’s requirements 8
Token released to RP
Identity Provider (IP)
Relying Party (RP)

14. Implementation Properties
Cards represent references to identity providers
Cards have:
Address of identity provider
Names of claims
Required credential
Not claim values
Card data not visible to applications
Stored in files encrypted under system key
User interface runs on separate desktop
Simple self-issued identity provider
Stores name, address, , telephone, age, gender
No high value information
User must opt-in

15. Information Cards Managed Self Issued
Provided by banks, government, clubs, enterprises, etc
Stored at STS
Metadata only on client
Self Issued
Stored locally
Assertions about me
Not corroborated

16. Windows Cardspace User Experience
Secure desktop
Trust Dialog
SSL
User in control
Private Windows desktop
Restricted account
Service does the work
Store ACLed, double encrypted
Roaming protection with PKCS#5
No user mode trojans, keyloggers or debugger can reach it
The most common attack, faking the auth UI of the target website, is very hard (borderline impossible). Wallet with different cards metaphor
CardSpace Trust Dialog
Validates certificate on first access to the site
Shows user certificate validation
Shows user company and issuing CA logo
Re-validates certificate on subsequent visits
High Assurance SSL Certificates
Higher bar for granting certificates
Certificates can include company logo
Industry wide initiative (Firefox, VeriSign, GeoTrust, Federal Bar Association)
Available late 2007
IE 7
Move the lock icon next to the address bar
Lock icon expands to show key certificate fields
Certificate is validated against URL and used to color address bar (green – HAC, white – SSL cert, red – cert does not match)
User in control
User always controls what information is released
Parties must identify themselves via Trust Dialog
User can protect cards with a PIN
And Windows CardSpace is an identity selector for Windows. You could probably use any number of ways for representing your digital identities but how do we give our identity in the real world? At a store I give my credit card, at a nightclub I show my driving license, at work I show my smartcard, in business I show my business card. In short, we use cards to represent our identities in the real world so it’s a natural metaphor for the user to adopt when choosing a digital identity to provide. CardSpace provides a familiar set of cards similar to if you opened your wallet or purse. When you want to identify yourself you just pick a card – no usernames and passwords! It’s consistent and secure. It has support for multi-factor authn like smartcards and kerberos and because CardSpace keeps track of where you have used your cards, it will alert you when a previously unvisited site – such as a phishing site pretending to be your normal online banking site - wants your credentials.

17. An Identity Metasystem Architecture
Microsoft worked with industry to develop protocols that enable an identity metasystem: WS-* Web Services
Encapsulating protocol and claims transformation: WS-Trust
Negotiation: WS-MetadataExchange and WSSecurityPolicy
Only technology specifically designed to satisfy requirements of an identity metasystem

18. Enabling CardSpace for relying parties
Declaring policies & eliciting the Identity Selector dialog is just an HTML fragment
Decrypting & checking token integrity can be made by any WS-Security compliant stack
SSL needs to be enabled
EV & Logotype certificates are a good idea, too
<object type="application/x-informationcard" name="xmlToken">
<param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion">
<param name="issuer“ value="
<param name="requiredClaims"
value="
</object>
Note everything is abstract here – we have said nothing about how we implement this using technology – and that’s the whole point
5) Note that when the user requests a security token they have to authenticate themselves to their identity provider in some way. The IP does not give a token to just anyone who asks (suppose it’s your bank and you ask for info) – you have to have the right to ask for the token. This step of providing credentials while getting a token to identify yourself to the RP confuses some people so make sure you explain it carefully and it is understood. We are at an abstract level here but remember the four methods of authn in CardSpace v1 are X.509, Kerberos, username and password, self-issued token. Any method that can plug in as an X.509 cert via a Crypto Service Provider will work. Other methods will be added post-v1.
8) Token is released to RP; RP reads claims and allows access
Important: the token format can be absolutely any format. As long as the RP asks for it and the IP can supply it we’re OK – that’s the point of the abstraction. The client does not have to understand the token format and cannot if the IP has encrypted the token so that only the RP can decrypt it. This revelation causes people to ask “how does the user know what’s in the token?” so they can approve its release. There is an optional “display token” which the IP provides to the client (encrypted for the client) which the client can understand. Those paying attention will then ask how do you know the display token == the token:
We make the identity provider sign the claims with their key. Therefore, they can't later repudiate the claims and say "We didn't say that." If the machine-readable claims and the human-readable claims don't match, they can be held accountable via human/reputation/legal processes.
However, in general, it's impossible for us to check that the machine-readable claims match the human-readable, because the claims can use any encoding whatsoever, and be signed using keys we can't decrypt. It's those very properties that let the Metasystem transmit claims from any individual system used by any identity provider.
So the "problem" is completely unsolvable via technical measures, which is OK, because it's completely solvable at a human/reputation/legal level, which is where a lot of the real-world solutions to breach of trust are going to have to reside anyway.
There is no way to keep the IP and RP from colluding if they are intent to do so, other than by making what is sent auditable. That is why we bind the display token to the computational token cryptographically. We have discussed this with important privacy and policy thinkers and explained our handling of the situation. Everyone has agreed and supported our approach. We need to get people to understand what it means to have an auditable system with digital signatures. And we need to get people to understand that technology must be combined with policy to solve these problems.
How do you put a checksum on a karma rating without involvement of policy and auditing (meaning people define clearly what they are doing and it can be verified that that is what they have done?)
Anyway, this is all implementation detail. This slide should is about the basic protocol.

19. relying party (website)
xmlToken
(signed &
encrypted)
token
decrypter
relying party (website)
xmlToken
(plaintext)
claims
extractor
ppid
456
user database
first name
last name
index into DB
123
456
789
phone

20. Implementing a relying party
Setup SSL for login page
Add HTML fragment to Login page
Decrypt & check token
Manage the token

21. Ubiquitous Implementation a Key Goal
Fully interoperable via published protocols
With other identity selector implementations
With other relying party implementations
With other identity provider implementations
Detailed implementation guide available
The industry has created an Open Source Identity Selector Consortium animated by Verisign, Red Hat, Novell, IBM, Sun, and others
Microsoft provides technical assistance
Example: Firefox Identity Selector

22. Summary Today’s identity crisis requires a strategic solution
The 7 laws and the identity metasystem provide one
WS-* sustains the identity metasystem with widely- accepted protocols
Microsoft implementing full support for an open identity metasystem in Windows
Microsoft not launching Son of Passport

23. Resources MSDN Community Website Forum Samples Test Websites
Community Website
Forum
Samples
Test Websites