I've received many comments like this one from Shigeya Tanabe:
mmm.. This InfoCard auth looks like it's not working with March 20th version of IE7. It says “IE has blocked this website from displaying non-secure contentâ€. instead of prompting to download ‘Microsoft Information Card IE Helper’.
So please hold off on further testing until I resolve the state of this. I've had a really busy week what with the MIX06 conference and everything else. I'll post again over the weekend.
In my recent post on Hardy Infocard Pioneers, I refered to the fact that the first “attack” had been made on the site. Apparently, I wasn't clear enough about the fact that I saw this as a good thing – something I appreciated. That led to this comment from Rohan.
Hi Kim,
An Attacker. thats a nice title, when the intention was not to “attack†but try to look at infocards from the other side. From another perspective altogether. Everybody seems to just nod heads when workflows and use case examples are explained. I have not seen many who have tried to disagree in the “openâ€.
Well, I am trying to do just that. Not disagree, but to look at it from another angle, and talk to you about my discoveries.
I’m sure that youd’ acknowledge, that I “did†inform you as soon as I logged into your site with FAKE info. Well, thats not called an “attackâ€.
As far as the “browsehappy.com†link goes, thats just a joke…
Like you said : All of us will be attacked and all of us have to work hard – and together – to create a safe internet. I AGREE with you. 100%. But lets be open to ideas that may be contradictory to our own….. My efforts are to create a SAFE internet. To point out issues and errors, so that one may work on fixing them.
So let me set the record straight. I think Rohan is making a positive contribution to thinking about InfoCards. I appreciate what he is doing for the very reasons he expresses. And if you go to his site, you'll see how creative he is.
I didn’t mean “attacker†in the “normal†sense of the word – I was talking about THE ATTACKER ROLE we refer to as identity and security people, when we attempt, as he did, to think things through from the viewpoint of an attacker.
I am delighted to have others in the community thinking through the possible attacks with me. More about that in a minute.
In terms of the browsehappy.com thing, it was obvious that Rohan was poking fun – and that's fine. I just appreciated the opportunity to rail, en passant, against a couple of the site's more dubious claims.
This said, I'd like to be very clear about the status of the work I'm doing here to InfoCard-enable my site.
There are two parts to this project.
The first is pretty much complete, and involved developing a way to consume and verify InfoCard SAML tokens using a typical LAMP server without installing binaries.
The second is the part I'm working on now. It involves experimentatng with how to use InfoCards concretely from a web site – in this case my blog. I'm learning as I go. After all, InfoCards are a relatively recent arrival on the scene…
I'll publish various elements of code as it evolves – but I'm writing this stuff personally as an exploration – it isn't a product, doesn't yet have a formal threat analysis, hasn't gone through security reviews, and hasn't even been seen by anyone other than me before appearing here. What you see is what you get.
My thinking is that the security threat model and reviews will be done here as part of the blogoshere process. And no doubt we'll find things to fix, working as a team.
InfoCard's Mike Jones has just finished a new technical paper that explains how a web designer gets web browsers to invoke the infocard experience. Here's the Table of Contents:
1. Introduction
2. Design Goals
3. Browser Behavior with InfoCards
3.1 Basic Protocol Flow When Using an InfoCard at a Web Site
3.2 Protocol Flow with Relying Party STS
3.3 User Perspective and Examples
3.4 Browser Perspective
3.5 Web Site Perspective
4. Invoking InfoCard from a Web Page
4.1 Syntax Alternatives: OBJECT and XHTML tags
4.1.1 OBJECT Syntax Examples
4.1.2 XHTML Syntax Example
4.2 InfoCard Invocation Parameters
4.2.1 issuer (optional)
4.2.2 issuerPolicy (optional)
4.2.3 tokenType (optional)
4.2.4 requiredClaims (optional)
4.2.5 optionalClaims (optional)
4.3 Data Types for Use with Scripting
4.4 Detecting and Utilizing an InfoCard-enabled Browser
5. References
Appendix A – HTTP POST Sample Contents
Appendix B – Detecting InfoCard Browser Support by Internet Explorer
Appendix C – Corrigenda
C.1. Self-Issued Card Issuer Syntax
C.2. Claim Separator Syntax
I thought the paper was clear – but I'm obviously way too close to know for sure. Mike ran several versions of it past a number of people from across the industry and “known to be interested” in browser matters. Many suggestions were incorporated.
If you have further comments, now is the time to get them in to us, and if you have questions or comments about things that are unclear, please don't be shy.
March 2006
Michael B. Jones
Microsoft Corporation
© 2006 Microsoft Corporation. All rights reserved.
The Identity Metasystem allows users to manage their digital identities from various identity providers and employ them in different contexts where they are accepted to access online services. In the Identity Metasystem, identities are represented to users as “Information Cards” (a.k.a. “InfoCards”). One important class of applications where InfoCard-based authentication can be used is applications hosted on Web sites and accessed through Web browsers.
This paper documents the Web interfaces utilized by browsers and Web applications that support the Identity Metasystem. The information in this document is not specific to any one browser or platform.
This document supplements the information provided in two other “InfoCard” references: the [InfoCard-Guide] which provides a non-normative description of the overall InfoCard model, and the InfoCard Technical Reference [InfoCard-TechRef], which provides the normative schema definitions and behaviors referenced by the InfoCard Guide.
This draft corresponds to the “InfoCard” support that Microsoft is implementing in WinFX [WinFX] and Internet Explorer 7. Other implementations following these specifications should be able to interoperate with the Microsoft implementation. The behaviors described in this document are subject to change.
1. Introduction
2. Design Goals
3. Browser Behavior with InfoCards
3.1 Basic Protocol Flow When Using an InfoCard at a Web Site
3.2 Protocol Flow with Relying Party STS
3.3 User Perspective and Examples
3.4 Browser Perspective
3.5 Web Site Perspective
4. Invoking InfoCard from a Web Page
4.1 Syntax Alternatives: OBJECT and XHTML tags
4.1.1 OBJECT Syntax Examples
4.1.2 XHTML Syntax Example
4.2 InfoCard Invocation Parameters
4.2.1 issuer (optional)
4.2.2 issuerPolicy (optional)
4.2.3 tokenType (optional)
4.2.4 requiredClaims (optional)
4.2.5 optionalClaims (optional)
4.3 Data Types for Use with Scripting
4.4 Detecting and Utilizing an InfoCard-enabled Browser
5. References
Appendix A – HTTP POST Sample Contents
Appendix B – Detecting InfoCard Browser Support by Internet Explorer
Appendix C – Corrigenda
C.1. Self-Issued Card Issuer Syntax
C.2. Claim Separator Syntax
The Identity Metasystem allows users to manage their digital identities, whether they are self-issued or issued by third-party identity providers, and employ them in contexts where they are accepted to access online services. In the Identity Metasystem, identities are represented to users as “Information Cards” (a.k.a. “InfoCards”). One important class of applications where InfoCard-based authentication can be used is applications hosted on Web sites and accessed through Web browsers.
This paper documents the Web interfaces utilized by browsers and Web applications supporting the Identity Metasystem. The information in this document applies to all platforms and browsers. These mechanisms are documented here to enable Web sites and browsers on all platforms to implement and use these mechanisms so they can utilize InfoCards for authentication.
Two other documents should be considered prerequisites for understanding this document: the InfoCard Guide [InfoCard-Guide] which provides a non-normative description of the overall InfoCard model, and the InfoCard Technical Reference [InfoCard-TechRef], which provides the normative schema definitions and behaviors referenced by the InfoCard Guide.
Numerous alternatives were considered for ways of bringing InfoCard-based authentication to Web sites. The design goals that led to the eventual decisions described in this document are:
The choices described in this document are an attempt to balance among all these sometimes competing goals and to achieve all of them as well as possible, given the realities of how the Web is used today.
This section explains the steps that a Web browser takes when using an InfoCard to authenticate to a Web site. Two cases are described. The basic case is where the Web site provides all the relying party functionality via HTML extensions transported over HTTP and HTTPS. The second case is where the relying party employs a relying party Security Token Server (STS), which it references via HTML extensions transported over HTTP and HTTPS.
This section explains the protocol flow when using an InfoCard to authenticate at a Web site where no relying party STS is employed.
Figure 1: Basic protocol flow when using an InfoCard to authenticate at a Web site
Figure 1 gives an example of the basic protocol flow when an InfoCard is used to authenticate at a Web site that employs no relying party STS. Steps 1, 2, and 5 are essentially the same as a typical forms-based login today: (1) The user navigates to a protected page that requires authentication. (2) The site redirects the browser to a login page, which presents a Web form. (5) The browser posts the Web form that includes the login credentials supplied by the user back to the login page. The site then validates the contents of the form including the user credentials, typically writes a cookie to the client for the protected page domain, and redirects the browser back to the protected page.
The key difference between this scenario and today's site login scenarios is that the login page returned to the browser in step (2) contains an HTML tag that allows the user to choose to use an InfoCard to authenticate to the site. When the user selects this tag, the browser's InfoCard support code invokes the InfoCard protocols and user experience, and triggers steps (3) through (5).
In Step (3), the browser InfoCard support code invokes the InfoCard identity selector, passing it parameter values supplied by the InfoCard HTML tag supplied by the site in Step (2). The user then uses the identity selector to choose an InfoCard, which represents a digital identity that can be used to authenticate at that site. Step (4) uses the standard Identity Metasystem protocols [InfoCard-Guide] to retrieve a security token that represents the digital identity selected by the user from the STS at the identity provider for that identity.
In Step (5), the browser posts the token obtained back to the Web site using a HTTP(S)/POST. The Web site validates the token, completing the user's InfoCard-based authentication to the Web site. Following authentication, the Web site typically then writes a client-side browser cookie and redirects the browser back to the protected page.
It is worth noting that this cookie is likely to be exactly the same cookie as the site would have written back had the user authenticated via other means, such as a forms-based login using username/password. This is one of the ways that the goal of “minimal impact on Web sites” is achieved. Other than its authentication subsystem, the bulk of a Web site's code can remain completely unaware that InfoCard-based authentication is even utilized. It just uses the same kinds of cookies as always.
In the previous scenario, the Web site communicated with the client Identity selector using only the HTML extensions enabling InfoCard use, transported over the normal browser HTTP or HTTPS channel. In this scenario, the Web site also employs a relying party STS to do part of the work of authenticating the user, passing the result of that authentication on to the login page via HTTP(S) POST.
There are several reasons that a site might factor its solution this way. One is that the same relying party STS can be used to do the authentication work for both browser-based applications and smart client applications that are using Web services. Second, it allows the bulk of the authentication work to be done on servers dedicated to this purpose, rather than on the Web site front-end servers. Finally, this means that the front-end servers can accept site-specific tokens, rather than the potentially more general or more complicated authentication tokens issued by the identity providers.
Figure 2: Protocol flow when using an InfoCard to authenticate at a Web site, where the Web site employs a relying party STS
This scenario is similar to the previous one, with the addition of steps (3) and (6). The differences start with the InfoCard information supplied to the browser by the Web site in Step (2). In the previous scenario, the site encoded its WS-SecurityPolicy information using InfoCard HTML extensions and supplied them to the InfoCard-extended browser directly. In this scenario, the site uses different InfoCard HTML extensions in the Step (2) reply to specify which relying party STS should be contacted to obtain the WS-SecurityPolicy information.
In Step (3), the client InfoCard code contacts the relying party STS specified by the Web site and obtains its WS-SecurityPolicy information via WS-MetadataExchange. In Step (4) the identity selector is shown and the user selects an InfoCard, which represents a digital identity to use at the site. In Step (5), the identity provider is contacted to obtain a security token for the selected digital identity. In Step (6), the security token is sent to the Web site's relying party STS to authenticate the user and a site-specific authentication token is returned to the InfoCard client. Finally, in Step (7), the browser posts the token obtained in Step (6) back to the Web site using HTTP(S)/POST. The Web site validates the token, completing the user's InfoCard-based authentication to the Web site. Following authentication, the Web site typically then writes a client-side browser cookie and redirects the browser back to the protected page.
The InfoCard user experience at Web sites is intended to be intuitive and natural enough that users’ perspective on it will simply be “That's how you log in”. Today, Web sites that require authentication typically ask the user to supply a username and password at login time. With InfoCard, they instead ask users to supply an InfoCard. Some sites will choose to accept only InfoCards whereas others will give users the choice of InfoCards or other forms of authentication.
A site that accepts InfoCards typically has a login screen that contains button with a label such as “Sign in with an InfoCard” or “Login in using an InfoCard“. Upon clicking this button, the user is presented with a choice of his InfoCards that are accepted at the site, and is asked to choose one. Once a card is selected and submitted to the site, the user is logged in and continues using the site, just as they would after submitting a username and password to a site.
Sites that accept both InfoCards and other forms of authentication present users with both an InfoCard login choice and whatever other choices the site supports. For instance, a site login screen might display both “Sign in with your username and password” and “Sign in with an InfoCard” buttons.
Very little additional support is required from today's Web browsers to also support InfoCard-based authentication. The main addition is that they must recognize special HTML and/or XHTML tags for invoking the InfoCard user experience, pass encoded parameters on to the Identity selector on the platform, and POST back the token resulting from the user's choice of a digital identity for the authentication.
Web sites that employ InfoCard-based authentication must support two new pieces of functionality: adding HTML or XHTML tags to their login page to request an InfoCard-based login and code to log the user into the site using the POSTed credentials. In response to the InfoCard-based login, the Web site typically writes the same client-side browser cookie that it would have if the login had occurred via username/password authentication or other mechanisms, and issue the same browser redirects. Thus, other than the code directly involved with user authentication, the bulk of a Web site can remain unchanged and oblivious to the site's acceptance of InfoCards as a means of authentication.
HTML extensions are used to signal to the browser when to invoke the identity selector. However, not all HTML extensions are supported by all browsers, and some commonly supported HTML extensions are disabled in browser high security configurations. For example, while the OBJECT tag is widely supported, it is also disabled by high security settings on some browsers, including Internet Explorer.
An alternative is to use an XHTML syntax that is not disabled by changing browser security settings. However, not all browsers provide full support for XHTML.
To address this situation, two HTML extension formats are specified. Browsers may support one or both of the extension formats.
An example of the OBJECT syntax is as follows:
<html>
<head>
<title>Welcome to Fabrikam</title>
</head>
<body>
<img src='fabrikam.jpg'/>
<form name="ctl00" id="ctl00" method="post"
action="https://www.fabrikam.com/InfoCard-Browser/Main.aspx">
<center>
<img src='infocard.bmp' onClick='ctl00.submit()'/>
<input type="submit" name="InfoCardSignin" value="Log in"
id="InfoCardSignin" />
</center>
<OBJECT type="application/x-informationCard" name="xmlToken">
<PARAM Name="tokenType" Value="urn:oasis:names:tc:SAML:1.0:assertion">
<PARAM Name="issuer" Value=
"urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self">
<PARAM Name="requiredClaims" Value=
"http://schemas.microsoft.com/ws/2005/05/identity/claims/emailaddress
http://schemas.microsoft.com/ws/2005/05/identity/claims/givenname
http://schemas.microsoft.com/ws/2005/05/identity/claims/surname">
</OBJECT>
</form>
</body>
</html>
This is an example of a page that requests that the user log in using an InfoCard. The key portion of this page is the OBJECT of type “application/x-informationCard“. Once a user selects a card, the resulting security token is included in the resulting POST as the xmlToken value of the form. Appendix A shows a sample POST resulting from using a login page similar to the preceding one. If the user cancels the authentication request, the resulting POST contains an empty xmlToken value.
Parameters of the InfoCard OBJECT are used to encode the required WS-SecurityPolicy information in HTML. In this example, the relying party is requesting a SAML 1.0 token from a self-issued identity provider, supplying the required claims “emailaddress“, “givenname“, and “surname“. This example uses the basic protocol described in Section 3.1 (without employing a relying party STS).
A second example of the OBJECT syntax is as follows:
<html>
<body>
<form name="ctl01" method="post"
action="https://www.fabrikam.com/InfoCard-Browser-STS/login.aspx"
id="ctl01" onSubmit="fnGetCard();">
<img src='infocard.bmp' onClick='ctl01.submit()'/>
<input type="submit" name="InfoCardSignin" value="Log in"
id="InfoCardSignin" />
<OBJECT type="application/x-informationCard" name="xmlToken"
ID="oCard" />
</form>
<script type="text/javascript">
<!--
function fnGetCard(){
Card.issuer = "http://www.fabrikam.com/sts";
Card.issuerPolicy = "http://www.fabrikam.com/sts/mex";
Card.tokenType = "urn:fabricam:custom-token-type";
}
//-->
</script>
</body>
</html>
This example uses the enhanced protocol described in Section 3.2, which employs a relying party STS. Note that in this case, the “issuer” points to a relying party STS. The “issuerPolicy” points to an endpoint where the security policy of the STS (expressed via WS-SecurityPolicy) is to be obtained using WS-MetadataExchange. Also, note that the “tokenType” parameter requests a custom token type defined by the site for its own purposes. The “tokenType” parameter could have been omitted as well, provided that the Web site is capable of understanding all token types issued by the specified STS or if the STS has prior knowledge about the token type to issue for the Web site.
The object parameters can be set in normal script code. This is equivalent to setting them using the “PARAM” declarations in the previous example.
An example of the XHTML syntax is as follows:
<html XMLNS:ic="http://www.identityselectors.org/2006/10">
<head>
<title>Welcome to Fabrikam</title>
</head>
<body>
<img src='fabrikam.jpg'/>
<form name="ctl00" id="ctl00" method="post"
action="https://www.fabrikam.com/InfoCard-Browser/Main.aspx">
<ic:informationCard name='xmlToken'
style='behavior:url(#default#informationCard)'
issuer="urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self"
tokenType="urn:oasis:names:tc:SAML:1.0:assertion">
<ic:add claimType=
"http://schemas.microsoft.com/ws/2005/05/identity/claims/emailaddress"
optional="false" />
<ic:add claimType=
"http://schemas.microsoft.com/ws/2005/05/identity/claims/givenname"
optional="false" />
<ic:add claimType=
"http://schemas.microsoft.com/ws/2005/05/identity/claims/surname"
optional="false" />
</ic:informationCard>
<center>
<input type="submit" name="InfoCardSignin" value="Log in"
id="InfoCardSignin" />
</center>
</form>
</body>
</html>
The parameters to the OBJECT and XHTML InfoCard objects are used to encode information in HTML that is otherwise supplied as WS-SecurityPolicy information via WS-MetadataExchange when InfoCard is used in a Web services context.
This parameter specifies the URL of the STS from which to obtain a token. If omitted, no specific STS is requested. The special value “urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self” specifies that the token should come from a self-issued identity provider.
This parameter specifies the URL of an endpoint from which the STS's policy can be retrieved. If omitted, the value “<issuer>/mex” is used.
This parameter specifies the type of the token to be requested from the STS as a URI. This parameter can be omitted if the STS and the Web site front-end have a mutual understanding about what token type will be provided, or if the Web site is willing to accept any token type.
This parameter specifies the types of claims that must be supplied by the identity. If omitted, there are no required claims. The value of requiredClaims is a space-separated list of URIs, each specifying a required claim type.
This parameter specifies the types of optional claims that may be supplied by the identity. If omitted, there are no optional claims. The value of optionalClaims is a space-separated list of URIs each specifying a claim type that can be optionally submitted.
The object used in the InfoCard HTML extensions has the following type signature, allowing it to be used by normal scripting code:
interface IInformationCardSigninHelper
{
string issuer; // URI specifying token issuer
string issuerPolicy; // MetadataExchange endpoint of issuer
string tokenType; // URI specifiying type of token to be requested
string requiredClaims; // Set of required claims
string optionalClaims; // Set of optional claims
boolean isInstalled; // True when InfoCard implementation is available
// in the browser
}
Web sites may choose to detect browser support for InfoCards and modify their login page contents depending upon whether InfoCard support is present, and which of the OBJECT and/or XHTML syntaxes are supported by the browser and supported by the Web site. This allows InfoCard capabilities to be shown when available to the user, and to be not displayed otherwise.
Detecting an InfoCard-enabled browser may require detecting specific browser versions and being aware of the nature of their InfoCard support. A method of accomplishing this for Internet Explorer is described in Appendix B.
The contents of an HTTP POST generated by a page like the first example in Section 4.1.1 follows:
POST /test/s/TokenPage.aspx HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Content-Length: 6478 Content-Type: application/x-www-form-urlencoded Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-sh ockwave-flash, */* Accept-Encoding: gzip, deflate Accept-Language: en-us Host: calebb-tst Referer: https://localhost/test/s/ User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) UA-CPU: x86 InfoCardSignin=Log+in&xmlToken=%3Cenc%3AEncryptedData+Type%3D%22http%3A%2F%2F www.w3.org%2F2001%2F04%2Fxmlenc%23Element%22+xmlns%3Aenc%3D%22http%3A%2F%2Fww w.w3.org%2F2001%2F04%2Fxmlenc%23%22%3E%3Cenc%3AEncryptionMethod+Algorithm%3D% 22http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmlenc%23aes256-cbc%22+%2F%3E%3CKeyIn fo+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23%22%3E%3Ce%3AEn cryptedKey+xmlns%3Ae%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmlenc%23%22% 3E%3Ce%3AEncryptionMethod+Algorithm%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2F04% 2Fxmlenc%23rsa-oaep-mgf1p%22%3E%3CDigestMethod+Algorithm%3D%22http%3A%2F%2Fww w.w3.org%2F2000%2F09%2Fxmldsig%23sha1%22+%2F%3E%3C%2Fe%3AEncryptionMethod%3E% 3CKeyInfo%3E%3Co%3ASecurityTokenReference+xmlns%3Ao%3D%22http%3A%2F%2Fdocs.oa sis-open.org%2Fwss%2F2004%2F01%2Foasis-200401-wss-wssecurity-secext-1.0.xsd%2 2%3E%3Co%3AKeyIdentifier+ValueType%3D%22http%3A%2F%2Fdocs.oasis-open.org%2Fws s%2Foasis-wss-soap-message-security-1.1%23ThumbprintSHA1%22+EncodingType%3D%2 2http%3A%2F%2Fdocs.oasis-open.org%2Fwss%2F2004%2F01%2Foasis-200401-wss-soap-m essage-security-1.0%23Base64Binary%22%3E%2BPYbznDaB%2FdlhjIfqCQ458E72wA%3D%3C %2Fo%3AKeyIdentifier%3E%3C%2Fo%3ASecurityTokenReference%3E%3C%2FKeyInfo%3E%3C e%3ACipherData%3E%3Ce%3ACipherValue%3EEq9UhAJ8C9K5l4Mr3qmgX0XnyL1ChKs2PqMj0Sk 6snw%2FIRNtXqLzmgbj2Vd3vFA4Vx1hileSTyqc1kAsskqpqBc4bMHT61w1f0NxU10HDor0DlNVcV Dm%2FAfLcyLqEP%2Boh05B%2B5ntVIJzL8Ro3typF0eoSm3S6UnINOHIjHaVWyg%3D%3C%2Fe%3AC ipherValue%3E%3C%2Fe%3ACipherData%3E%3C%2Fe%3AEncryptedKey%3E%3C%2FKeyInfo%3E %3Cenc%3ACipherData%3E%3Cenc%3ACipherValue%3ErBvpZydiyDzJtzl1%2FjUFX9XAzO1mOR q0ypPLjh%2FBagXcfZeYwWD57v4Jvn1QwGajadcDASCisazswn1skdkwgmd4IUWJpPMRH7es9zY0U vnS4ccsakgDcmscq3pDYTrxbSBfhdvrzjDiHC2XCtowOveoHeB51C5N8UAbff18IxCNtkWO8y3wLH VGdvwaDOSakK%2FK%2Fv1UgXIc51%2FtYvjeFGeGbbSNxo8DTqeDnAMQ%2B4Y%2B1aUGhI%2FtbSr EyJECkDgtztcxhrumbupKO%2BogWKUTTpSt851xjOFxAMiVaPZ%2FAm8V8H3ZLsR087sX%2FJ%2Bn bRqze%2BfbdUwimN5pNoJDdMnF%2BEDLass1dPsvhL4EXzuIp5deGBaqAIoaOMEUW7ssuh1PtwkEM eqwlOzOhu%2FHtwP1qh3D02U59MtyQnJMD5UwIwO7sZJl6%2BPg6Zp9HHtKKUMnkguvFmhyXS4BFS ZVxPl18i%2B0MLO1um5dejEFd4nwGO%2FmNw6yEI8DdGVjXcYOT6JhPz9rHNh9%2F%2FOj5snJfL6 j2sg0EvIYoRs%2BhT4sdHZ95tGAiwMwT6cFOXbAQZUbYTr1ZOC6XPsfL2CFwiTM3mI%2Blco4Hc%2 F7IakIA8jwAJdtnd2mGuV67ZbY1mzibM1LUApixZj59El83ixctSQbV7iyywQ4IYN2CAq%2BCLMdl R%2BDHfgEe8O3IVaGBDUEcd2MYimEiA7Yw3NIDrC14SbLzNvU702HpVJMeYv9q6S9xIVGApSrARsw RFXyMbkMDp5WIQaJEXon7qLcsZONpdlX9bCcmaiikdpxmCeyS638te%2FhGBLmYJSQ0stf7BhA6E0 kwDRgdwsAa88bODiWHek0vDhAN4HlXFZ%2BCxp53L9Mmvy%2FCAOI%2B9OkPL2yxS22yjWQxom%2F yZuawsK98JHVShsIVmmbKvRM6xJwvHDSzuBAOlQKS%2FMHcFZn8vHZR4lMhm5nL3F%2B%2BumMKh0 vMuKk6JiCqG9OEj996bVIIkLzESU5Z5vT6I1Kr9Brdx8ckDElipdH3x54WVfaItHJTYU%2BsxIR1T 25fi9k%2FOc%2FMX7Q%2B6NSDs4nGqkn4rzqpez9BUWNZw7caVOrDeao85f%2FiDCGymtl0A3JaSZ dTKfzHLGmUfSkCAlVeisdvB6R7uBw8tR%2BZlgLIGS28wppFlnUYvSK7DnPrzId%2BGfHwLfL6WA% 2FEzBMMgppb5Vi%2BauHq%2BHxpCamlkrcUkzagbwNkGV8TfafkqUvRwJbxRwNVPI%2F%2Fxs%2Fp Lcu1dh6eKcmU00%2FNx0zNOScd9XoeEU3zsV78PgvPIBT4EDugdv4bMR6dExXvZBl%2F84b1gOMhK ZRplF8t6EAc4LCct01ht7VOVNz25NtP27ct9QPrDJc%2FoxihT4Df6NV3l4vlTnu%2B%2BzVB%2BH JAxNkiO9gx3uLUJM9XEZCDzZKihaBk2y%2F3RhsJpABVneUd%2B3sCRbQXhgKYNBHZyRAUGpMDLhL qpjoF9x%2FNvUujQ5DBLJafxxzNVshG52jRz%2BikhCNhJDDbeA5MQ8Q7QsYcKDC0DBFsewtWaA%2 FsKxl3JU6hyTotnFS%2FoS2EzbOSvn25qZuBERsZ3w%2B5WMkRzfQadyIYOSv2Df1YoljubDKy1l9 St%2FbCIBgXbVIZKYtQ%2BLyepxxFjrN7cWo2aYFnB6YLurg4USJwhXzcGcvA3%2BR5dRT6Fr37U6 OcHc%2Fz2MaZmn1cQWiDGNxHtRVxEvirBc1x47hWfSRjrKzf3orL5LzgMlYc7Iwclw2rbeWljCqOb oV3d71ez%2FvNz1pxEMi4w8yUAQL8p%2FRCZ%2BpzvsgORu4RWKWiSwbl7AN0J3jiWShyZgDmxd2O DDYffXjNiuH1mQWnDTkJX1ig88mqjhOYJEal0W6L0ErwrRIy29tOiAvXZANC8kA1HexulH0e38x8E IOaVaJtNz9mqrnmnp4GdZ38txV%2BCUeWHOZaHLF4xkdtRxMAu%2FbzQ03YmUOhgxqkTfNzV6Ymne v2nv5VsyQGJaQsNjb0M4yOe6kX2qNTwKBN2%2Bp%2Fz3f15i8KuGCgBcfP%2BP9xBizBeo7FbFtyo 2pfFhzBPmZeSOJ6kEbF1yQKHYQAT5iZ4SyTIfqqmwGxsQpWMstx3qJF8aW8WFzU1qXcC1LmgClg19 rx9NYFaQshX4f729B9Ue5MX7gTrMgwAnlXty9BsoP7nzGbr3HSXy8pR%2BimuAFW3c2NaQSbjSH5Z FOr7PZdLHsNVJzFIsaufAwr0CAEtvlPJUt7%2B%2FE5MQsMsVqMoXFmefgdxbvY1Ue6MX1wtuJYY1 PAX7MHTyRUR3RfJDO054EoflVTwNE1fmocUXUh5rtFFuzy2T%2F2Y6pLAARXzo8uslAuH67VkuXv% 2BEMc7e3ogbf5%2BROsgJirZS6qkcYpfEUwqHiQYLnSIP4bt%2BWI5j1bxs7yzcSCkNZ2rd%2FHWr A41AyGMfYzqxfGcrOaxHsds3JUcByB5Zw17W58GBC32Iusqa69BFTPagEapM0Fb5CbTqXnWTNNB5J t40BVZvLv3u5oy%2BBRaMKXZhwnbT2WUTp0Ebsn17xvte52B%2BLMlSWJn96Nl5thd%2Ft1D7PlWA sUvpJAd0UHPizCkY8VIhcXTrsSyEwer2J2I9TQTUosmssFjoP8Lx9qMfXo0eGVmneV8kVBtu4J7N1 QmWfV%2B%2FK8vGbCwW3Gm%2FEUlOO4ZbbK39y0JgNQ7fshxHr5Hdtd%2F6S%2FQkb6NPVDwn7Srh Y0diWujXz5QlIYBSN7vDfMun3yF%2BGbmMExZ8MkOthuYkgMS9qiFoJGUXGyELsJfxbzdcRE9iyJn p88L4%2BCtcO3l2JxIhMAgxOZx42RfAiDV1Gbpa4f%2F0urmWQ2VK7uZ%2FlViVrGAJ2kpH0EfwYE Mb2YYT8FFjogqEpDSJX48BLIh1TE4nMbqQVG1cksCGDc0XyGKaF5Z7Ikw493Xz0JQ0BZvaf2Kceb7 MUZlsU1DSHcQQ9X%2Bxu9RcgUePJEe9BgCMpZ5Kr6r43qyk79noBSgrsSkDhT5sg%2Fc20RHQB8OX %2BC4r3XGQFWF2m2j0xTc%2Boy14xqUmSB2qJtuWGOXDJspejDRP1GIfFnqDFdqSO3%2FkV9AC5Ee 39iJGv8I%2B5nErtQao645bCytn4B2bJah8R2fXLs8Dd4%2BC2ykxVrLxTUmJaGqd2RK%2F6t1E47 l%2B90Vp4WEzC0CFXXt9XNqdVjo2bZsXbfKQgO2zT2q2qCsgwbxVzIF5y39R%2BrkSkX16uuz3q6w n3I5RI9M8Hn3DCzzv6Ms4rYxYuiqxaIcb7DgjI2fk1bdyiiRjSxzpCHpK6CWjBD8DPQYdkqGr%2Bs oWeSvHvPLMSDxEPzwlnaxysRXzKphHUeUa2CCqcpagux2mbKkwHSXemX9I3V3AhPePp5XI5eCRiy3 D4%2BcBXOydie94Nz9DIhW749hPiVD9CioAgyqgAzFwCxEEUCXKTzu9xXX4DXg9b3CUfGzwERtY7x TGT2y%2F9i7r5Xs0lrKi9ftws4JO5v%2Be3WuAEtWv0w%2FVKCl1WwTbV9xtx%2B4RZQ3%2Fewvv% 2F0GqiiSrhiVBGuCDaQs7stwqfkF3vFgGXmmODGTIkIxvYm2fzcEfq4A6LRp5RkYyJyUTF87c56tn Qa%2Bo3xeiX5WRJybpabrRou09vyWLdlkhcUaBElGWB7iYUJ9bCltByEdNZnuDV%2FXlfnmDARKp8 RVN028czIk57wQMuizgWrM6S9Ku20noDmLgbT554UBf7FnjRWOb%2FF9OJuPpUcARBPrfuqTcOsBq tZr7AJl3zz%2F53mpyn9rgzw5gBLgkvrdbciabJOAacccTDEB5kEzCLuprC3SlVedhgY%2BMQ5%2F xgN%2Faf3TtJiBKFvb1V37BlbXXGosnPFcoH8I0XbqW5FSsxmcnpg48poJcB7j5eHq7Y%2F01RLb4 iMmzNap4%2BFg2F3LrwOI0Wk7ueIjgFd5KJ1iTda1ivGU%2Fchr9aTNpM5HiLb2fDW0pZ%2FFBJcI XxpT9eNY%2FpVj5pnTW2ubpPnBulPOQTLCi1EOxbl33wnhUIfnGiVWJdrls2j3GWgqOnrYUbP%2FX tNJqIucnMYGqPbcGIF2QRuiwD%2FiTRMvCRCmdCsYE%2FaXjOMhskX7KYC%2B9iG%2FT1wQRbfHSK WD%2Fpv450OVDsfc1Adq6FCr1LesDNTew%2FF8Z3SiHnWS76OVsNM2SB%2FhMP67iu5UWVkb3%2FQ qCN0aosOPs2QX0XBCZFmN6p3FhFnXPbAbaGz9y6KzUiUxC03U0fZcToKl4y%2Bw0P4IvxpjVt4t8b 84Q9hiBxd5xu1%2BRE973a%2FyIWO%2Fit1MdUSmxWakxWuGxDnQxwkNCN7ekL%2FQ%2B6FItm86b w9cc%2FMiI7q2fK7y7YAzM3tmamhF1%2FWJNj1lH0vh%2BhNehJlLlb4Z%2F9ZtxMWV4LVTyrFaF1 zyCEqcKUTk0jc%2FXDwyKZc%2FSV9EOoPk2fVnmzs3WkA74GB%2BWtjdvQjSmnJYtPkMNsikHw%2B RyB1hTkYbn3iQ6BUiJ0v97j7MVZHxCa1KS3t2gx8H7ts6Tfy5il89xVUdiZwfj0w06g199qlAqUMZ EWxh0%3D%3C%2Fenc%3ACipherValue%3E%3C%2Fenc%3ACipherData%3E%3C%2Fenc%3AEncryp tedData%3E
An un-escaped and reformatted version of the preceding xmlToken value, with the encrypted value elided, is as follows:
<enc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:enc= "http://www.w3.org/2001/04/xmlenc#"> <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#"> <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1 p"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> </e:EncryptionMethod> <KeyInfo> <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oas is-200401-wss-wssecurity-secext-1.0.xsd"> <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-mes sage-security-1.1#ThumbprintSHA1" EncodingType="http://docs.oasis-open.org/ws s/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"> +PYbznDaB/dlhjIfqCQ458E72wA= </o:KeyIdentifier> </o:SecurityTokenReference> </KeyInfo> <e:CipherData> <e:CipherValue> Eq9UhAJ8C9K5l4Mr3qmgX0XnyL1ChKs2PqMj0Sk6snw/IRNtXqLzmgbj2Vd3vFA4Vx1hileSTyqc1 kAsskqpqBc4bMHT61w1f0NxU10HDor0DlNVcVDm/AfLcyLqEP+oh05B+5ntVIJzL8Ro3typF0eoSm 3S6UnINOHIjHaVWyg= </e:CipherValue> </e:CipherData> </e:EncryptedKey> </KeyInfo> <enc:CipherData> <enc:CipherValue> ...= </enc:CipherValue> </enc:CipherData> </enc:EncryptedData>
Script code can detect browser support for InfoCard within Internet Explorer by testing the userAgent string to determine whether the browser version is greater than or equal to MSIE 7.0. A second issue with Internet Explorer 7 is that the InfoCard support might not be installed (because WinFX is not installed on the machine). This can be detected by using the “isInstalled” property on the InfoCard OBJECT from scripting code.
This appendix describes the known differences between the preceding specifications and the early implementation included in the build of Windows Vista distributed to MIX 2006 attendees.
The syntax for indicating self-issued cards in the MIX 2006 build is “http://schemas.microsoft.com/ws/2005/05/identity/issuer/self“—not the URN syntax “urn:schemas-microsoft-com:ws:2005:05:identity:issuer:self” documented previously.
Claims in the “requiredClaims” and “optionalClaims” list are separated by commas in the MIX 2006 build—as opposed to using spaces for separation as documented previously.
It's currently hard to locate and install the right software to try out InfoCard on the identityblog but a bunch of intrepid explorers have now actually done it, making me feel a deep wave of geek comraderie.
In fact, the subscription list has doubled since yesterday (doubling once every twenty-four hours may not be sustainable!) And we've had our first identity attack! Things are poppin’ – so to speak – techies bumping into a new technology and a lot of fun.
You can see a sanitized list of subscribers here – the uncategorized entry at the bottom is the attacker (more later).
So let me start with Ashish Jain. Looks like he is starting an identity blog called iTickr.com. He calls this posting Welcome InfoCard:
As a core Java / ex-BEA guy (if I only got a penny every time I told customers to stay away from .NET), I never thought I would say this: it's been fun playing with Infocards for the past couple of days. Sure, it takes a lifetime to figure out what you need and what's the right place to download (MS overusage of ‘setup.exe’ doesn't really help)… but once you have that figured out, it's all ‘click’ and ‘play’. Managed to log into Kim Cameron's Identity Blog using my self-issued Infocard. This is what I did:
- Harass my IT guy to get a vanilla m/c with WinXP2 (I wasn't going to risk my own).
- Downloaded (here) and installed WinFX Runtime Component.
- Updated some COM+ Hotfix (the installation process guides you there).
- In my control panel, verified that I have the extra icon ‘Digital Identities’.
- Clicked ‘Digital Identities’ icon and created some dummy infocards (the interface is pretty intuitive).
- Downloaded IE7 from here.
- Accessed identityBlog.com and clicked on login.
- Selected Infocard as the option to login.
- Installed the ActiveX control (it's a test machine so I was little more liberal in clicking ‘Yes’ to every download).
Screen started greying out… (very theatrical… they should add some sound effects too). Picked one of my self-issued inforcard and I'm in.
Some of the screen shots here.
Plan to put together a SP application and hopefully use some managed Infocards in the coming days. Stay tuned.
So cool. Before we go further, let me say that Ashish is totally on the money here in making sure he rounded up a test PC. Please follow his example.
I've actually installed this stuff on my production laptop, which is insane, but this is only because I am prepared to sacrifice deeply to get a feeling for what it's really like to live in an infocard world. (Someone just called me the “Madame Curie of Identity”). I need to understand the experience issues as well as I can.
Be prepared for minor changes with breaking periods before InfoCard goes to release. In case of doubt follow the implementor's guide when it comes to futures.
If you think installing the software is hard, upgrading it is just not supported. So use a dedicated or virtual machine.
I like Ashish's comment that the InfoCard desktop is, well, “…theatrical… they should add some sound effects too”. The goal is to draw the user into a ceremony where he or she will be on the lookout for abnormal behavior – in accordance with the sixth law. And yet, not to do something that would grate on your nerves as you get used to it. It's pretty clean.
OK. Now let's move on to the next new visitor. I'm talking about Caleb Baker. I haven't said enough about my team, and I want everyone to know how much I like and appreciate these foks. They have worked relentlessly to get this stuff out.
Caleb is one of the guys who is most critical to our InfoCard team. He works in the test organization, building automation for the Identity Selector and other components. If anyone knows what components work with what others, it's Caleb!
Testing this kind of project is unbelievably complex given the security issues. Imagine doing UI testing on a product when your test programs can't even see the InfoCard screen (because they are running on a private desktop)! It boggles the mind! But Caleb always seems to be in a positive mood.
One of the great things about Caleb – and his buddies – is how deeply committed he is to the privacy and security aspects of InfoCard. Few architects are fortunate enough to work with people who go so far to make sure theory and high level design principles are being applied in every nook and cranny of a project – with no shortcuts. I'm very grateful.
Finally, last but not least, there is the inimitable Rohan Pinto.
Rohan is from Sun, and blogs about infocards here. He is working on this stuff as a personal initiative at this point, and he's right out there in trying to understand it. In fact, he was visiting my site and using infocard on it even before I had finished porting it. He actually stunned me – I thought there was some kind of an error since it never occured to me that someone would be using the system before I had even announced it was working!
Rohan tells it as he sees it, and this posting is no exception. First he shows a graphic that proves he has logged in, which is great. Then he notes that the current incarnation takes you to a dashboard where you see a link to browsehappy.com. He points out:
The first page of browsehappy.com has text that reads as : “Internet Explorer can make your computer unsafe. Why not switch to a browser that's more secure?”.
I read that and thought…. {{{nothing}}} I Know, I Know, browsehappy.com and wordpress are interlinked…
I have to smile. All of us will be attacked and all of us have to work hard – and together – to create a safe internet. So the kind of stuff on browsehappy doesn't even register with me – or, I suspect, with my long-tail subscribers.
Back on the subject at hand, Rohan continues:
I sent an infocard with Kim's own FirstName, LastName and email address (because from Kim's infocard invoker code, I saw that the only info he requested from an infocard was just the firstname, lastname and email address) and was able to login with that infocard too. However either with my own infocard or with a FAKE infocard with Kim's own info, I could not do much on the site. But the point is that regardless of the authenticity of the user, a “user” was provisioned on his blog.
Actually, the way the system works, you start off as a “subscription requestor”. You aren't recognized as a subscriber until you respond to an email sent to your email address.
When Rohan made his FAKE card and posed as me, I was the one who got the invitation to validate my email address. Clearly I didn't – it was obvious to me that someone was pulling my leg. When I've finished the implementation, it will also be impossible to socially engineer anyone into inadvertantly confirming an email. More about this later.
The email verification stage explains why, in the screen shot above, the bottom “cameron” subscription requestor is not shown as a subscriber. Over time, the fake registration attempt will time out and be deleted.
The net result is that the people who are promoted to subscriber can use their infocard to post comments on the site, wheras the fakes cannot.
None of this is yet implemented as well as it should be. I'm still experimenting.
But for people interested in trying things out, after you've logged in using an infocard and been approved through the mail validation, click on the “view site” portion of the dashboard. That takes you to the public identity blog. Then click on a “comment” link and leave a comment. It bypasses the moderation queue and gets posted immediately.
Using my subscriber InfoCard, for example, this is what I saw when I went to type in a comment:
I pressed “Add my comment” and it was immediately posted.
Here are the first three InfoCard based autoregistrations at Identityblog. Email addresses have been doctored to protect the innocent (and even the not-so-innocent). I'm still thinking about the data minimalization issues.
Pete Rowley blogs here and Pamela Dingle blogs here.
As I said, all this is still very much a work in progress only for the strong-hearted.
I'm going to be posting a video of the user experience this weekend so everyone can see what it's like.
Pete Rowley, identity guru from RedHat, is one of the first to have logged into my site using an infocard. His report:
Kim Cameron blogs INFOCARDS ON IDENTITYBLOG which is good news for open source because Kim recently converted his blog to WordPress on the LAMP stack. It is also good news for InfoCards and the identity meta-system since according to Kim’s own laws of identity the meta-system is required to be platform agnostic in order to ensure success.
If you are itching to try out InfoCards be advised that it appears that only the combination of Windows XP SP2, WinFX, and IE7.0 Beta 2 will work. Vista appears to have issues. Registration to the site is painless, present your InfoCard as you would to log in and you are sent an email with a link to confirm. That is it.
Since this is an ongoing effort to integrate InfoCards with WordPress you should expect to see missing functionality, for example, having logged in you are still required to enter your name and email address in order to leave a comment.
I look forward to seeing the code.
Pete is right. At this point in time you still have to diddle and twiddle a bit to get the “right combination” of software for all the alpha and beta pieces to work together properly. I'll be posting something about how to download the magical bits combination.
He's also right that there are problems with InfoCard in the current version of the Vista beta – you are better off running it on XP for the time being. We have Vista bits where most of these issues are fixed, but not in a form we can release.
It's also true this is a work in progress – I appreciate Pete's support in helping set expectations.
A while ago I mentioned I had written some PHP code that would InfoCard-enable my site.
Problem was that when I went to put it onto my production server, I discovered that it runs the latest version of WordPress, and handles users and registration quite a bit differently than does the version running on my test machine.
I basically like the changes, but they have cramped my style a bit.
Now I've got things working again, though there are still bugs for me to fix. In particular, you can get into wierd states if you edit your profile – please wait a while.
Also, some of the user experience is still pretty “basic”. Like what happens if you click on infocard login and don't have infocards installed. When I have some time I'll make that take you to a page that tells you what infocards are, how they work, how to install them, and that sort of thing. But for now, the behavior should appeal to lovers of cryptic error messages.
A bunch of people have been downloading the InfoCard client and trying it on my site. Now it should work. Next I publish the source, and will do a code walkthrough, explaining the tokens and how to use them.
This stuff is all very alpha right now and there are things about WordPress that I don't fully understand. So, together we should be able to have some fun. People may have hints about my “use” of php as well. Too bad about this architect thing – I do love programming.
By the way, even though there isn't an open source version of InfoCards available yet, I hope my demonstration of what you can do on the LAMP stack helps advance the availability of InfoCard on non-windows systems.
UPDATE: The token handling code is explained here and includes a zip. I still haven't finished writing up the tutorial on what you have to change in WordPress.
You can now make comments without waiting for me to approve them.
By the way, point us to things you've written or like.
Thanks,
Kim
Click here to go the blog's main page.
A friend sent me recently to a web site that I think has many lessons to teach.
These lessons are layered like the skin of an onion, starting with a threat analysis of RFID. The authors (Melanie R. Rieback, Bruno Crispo and Andrew S. Tanenbaum) do a great job not only of thinking through and prototyping threats, but of explaining themselves in a paper called “Is Your Cat Infected Wiith An RFID Virus?” Reading it you'll see this is not a rhetorical question.
The site has many other treats as well. For example:
To make clear what kinds of problems might arise from RFID hacking by amateurs or criminals, let us consider three possible and all-too-realistic scenarios.
A prankster goes to a supermarket that scans the purchases in its customers’ shopping carts using the RFID chips affixed to the products instead of their bar codes. Many supermarkets have plans in this direction because RFID scans are faster (and in some cases can be done by the customers, eliminating the expense of having cashiers). The prankster selects, scans, and pays for a nice jar of chunk-style peanut butter that has an RFID tag attached to it. Upon getting it home, he removes or destroys the RFID tag. Then he takes a blank RFID tag he has purchased and writes a exploit on it using his home computer and commercially available equipment for writing RFID tags. He then attaches the infected tag to the jar of peanut butter, brings it back to the supermarket, heads directly for the checkout counter, and pays for it again. Unfortunately, this time when the jar is scanned, the virus on its tag infects the supermarket's product database, potentially wreaking all kinds of havoc such as changing prices. Emboldened by his success at the supermarket, the prankster decides to unwittingly enlist his cat in the fun. The cat has a subdermal pet ID tag, which the attacker rewrites with a virus using commercially available equipment. He then goes to a veterinarian (or the ASPCA), claims it is stray cat and asks for a cat scan. Bingo! The database is infected. Since the vet (or ASPCA) uses this database when creating tags for newly-tagged animals, these new tags can also be infected. When they are later scanned for whatever reason, that database is infected, and so on. Unlike a biological virus, which jumps from animal to animal, an RFID virus spread this way jumps from animal to database to animal. The same transmission mechanism that applies to pets also applies to RFID-tagged livestock. Now we get to the scary part. Some airports are planning to expedite baggage handling by attaching RFID-augmented labels to the suitcases as they are checked in. This makes the labels easier to read at greater distances than the current bar-coded baggage labels. Now consider a malicious traveler who attaches a tiny RFID tag, pre-initialized with a virus, to a random person's suitcase before he checks it in. When the baggage-handling system's RFID reader scans the suitcase at a Y-junction in the conveyor-belt system to determine where to route it, the tag responds with the RFID virus, which could infect the airport's baggage database. Then, all RFID tags produced as new passengers check in later in the day may also be infected. If any of these infected bags transit a hub, they will be rescanned there, thus infecting a different airport. Within a day, hundreds of airport databases all over the world could be infected. Merely infecting other tags is the most benign case. An RFID virus could also carry a payload that did other damage to the database, for example, helping drug smugglers or terrorists hide their baggage from airline and government officials, or intentionally sending baggage destined for Alaska to Argentina to create chaos (e.g., as revenge for a recently fired airline employee).
The links below give more technical detail about possible attacks and how to prevent them. The authors suggest that you read them in order.
