Category: Identity

Age verification roundup

by Tateru NinoTateru Nino at Second Life Insider has done a roundup of age verification issues arising from Second Life's experiment in controlling access to adult content. 

There's a lot of talk about age/identity verification going on, so I've done a pile of reading of material and logs (thanks for everyone who has provided links, logs and other information to source from) and condensed them into a not inconsiderable bulleted list, below the fold.Longer than your hand, people. Grab a cup of coffee.

  • Credit cards do not provide proof of age. In some areas and with some card providers you can obtain a credit card compatible card before you can talk.
  • Verification costs. It will be available at a token fee for premium account holders, but the brunt of the verification costs apparently will be borne by basic account holders. Linden Lab is passing along the costs of verification.
  • Mobile phones do not provide proof of age. In the UK, more children under 12 possess a mobile phone than adults over 18. In the USA, almost 50% of children have a mobile phone.
  • Driver's licences are not as widely held as you might think. Particularly the old, infirm or handicapped may not possess them. Areas with highly developed public transport systems, or poorer nations may have low penetration of these credentials.
  • Online verification does not verify the person, only the validity of the documentation that person provides. The person need not provide their own documentation for verification to be successful. Therefore, this system can only realistically be used to shift blame and does not constitute a method of verification or trust.
  • The status of a minor who has provided false verification information can (apparently) no longer be contested. If it says they're of a certain age, would it be harassing behavior to attempt to challenge that?
  • Linden Lab is apparently wishes to use a third-party company to keep verification costs down, and to prevent access to or storage of verification information by Linden Lab employees.
  • The age at which you are considered to be permitted to access ‘adult content’ varies from country to country. In most, the age varies between 12 and 25. A very few jurisdictions do not permit it under any circumstances. In most US Jurisdictions the age for the apparent class of adult content Linden Lab intends to grant access to would be 21, not 18.
  • Having taken steps to attempt to verify the age of a user, and then granted them access to adult content, does Linden Lab them become liable if you are still not eligible to be transmitted adult content in your jurisdiction? Does it even matter if the age/identity is accurate or not?
  • The verification provider may not demand or require any information from you. However, they are under no obligation to provide verification for you if you do not willingly provide it.
  • Integrity Services was initially given as the verification provider, however there is good cause to believe that the provider will change before plans go ahead.
  • Merely requesting an SIN identification from a Canadian citizen constitutes a legal offense. This policy may extend to other forms of identifying information in various countries.
  • Linden Lab provides only very vague guidelines for what does and does not constitute ‘adult content’. These are “adult content is that which is overtly, graphically, or explicitly sexual in nature or intensely violent”, which obviously leaves a lot of open questions.
  • The guidelines of most nations are vague on what constitutes adult content. In some cases, certain kinds of political content may fall under this classification. In India, “scenes that are a threat to the integrity to the nation, and those which disturb the friendly peace between nations” are classifiable as adult content.
  • Flagging parcels that contain adult content is mandatory.
  • Adult content flagged parcels must be within Mature sims.
  • It is inevitable that the judgement of an individual based on their own society's and community's standards and norms will unintentionally disagree with the judgement of one or more other residents or Linden Lab staff members. What will happen then? Will Linden Lab exercise editorial control, or assign punishments or penalties?
  • Verification may not be accessible to Linden Lab or verification service employees but must be archived for a period of time that may changed or extended by law before that that period expires. Can it be extended by other means (eg: Company policy?).
  • Archived verification data may be accessed during an audit. Who can initiate an audit of this data, and under what circumstances?
  • Will this archived verification data be subject to the European Union's DPA legislation, as would be required if any EU citizen's data is stored/archived?
  • Do you know what your nation's policy is on providing your passport number to overseas third parties?
  • The Second Life website already requests that users state using a check box that they are over the age of 18. By checking this box, users are making a statement that may be held as truth in a court of law. In short, they can and will be held responsible if this statement is later shown to be untrue. Why is it necessary for Linden Lab to perform an expensive operation like this that appears to only increase their overall legal exposure? What are we missing?

The author concludes:

Whew. What did I miss?

Jeff Bohren on role of CardSpace

Jeff Bohren at BMC Software has an interesting take on CardSpace and TEG – as well as other related matters.  And in this posting he says that BMC Software will be participating in the interoperability event at the next Burton Catalyst.  This really adds to the momentum. 

There will be a User Centric interoperability event at the next Burton Catalyst in SF. This will bring together several IdM vendors and open source projects to demonstrate interoperability between different implementations of Cardspace/InfoCard and OpenID. BMC Software will be participating. We will also have a hospitality suite the following night. I will be there so if you want to drop by I would be glad to talk with you about IdM issues.

Mike Jones from Microsoft has some great Cardspace/InfoCard resources on his blog. If you are interested in this area, you should definitely check this out. You should also check out Pamela Dingle’s introduction to Cardspace.

Microsoft has recently announced that they have sold over 40 million copies of Vista in the first 100 days since its release. Obviously not all of those are installed and in use, but this still a lot of users. And every one of them is a potential Cardspace user.

If IE isn’t your cup of tea, there are several other option available. Xmldap.org has a plug-in for Firefox. I gave it a try, but for some reason I could not use it to do InfoCard authentication to Kim Cameron’s blog, which you can obviously do with CardSpace.

There has been a recent spurt of debate over at the TEG mailing list about Cardspace. I don’t want to waste TEG bandwidth on what is really a tangential issue, so here is my take on the value of Cardspace/InfoCard.

The best way to think of the value of Self-Issued InfoCards is to think of them as analogous in feature to end-user SSL client certificates. In essence they are a holder-of-key style authentication that can be used by itself or in conjunction with a password based authentication to dramatically improve the security of the authentication process. Like client certificates, InfoCards authenticate the computer the user is on, not the user. They further have the advantage of presenting a very user friendly graphical mechanism to select what identity should be used.

While all InfoCard implementations have this value, Cardspace goes further and adds additional features to thwart phishing, man-in-the-middle-attacks, and software key loggers. If the US banks where smart, they would adopt InfoCard as their solution to comply with FFIEC guidance for on-line banking. Cardspace/InfoCard could be used as a second factor of authentication to use for financially sensitive transactions. Not as a replacement for passwords, but as a supplement. And best of all (to the bank) there is zero cost on a per user basis.

For enterprises there is an important potential value for InfoCards, and it has nothing to do with internal authentication. The value is by using InfoCards, an employee of a company can easily choose different identities depending on whether he is representing the company in a specific transaction or not. It has to do with separating personal from professional personas. A company could issue a managed InfoCard to each employee for use for their professional persona and establish best practices for using their self-issued InfoCards for personal business. Now you can do this without InfoCards by creating multiple IDs, but as a practice no one does that.

Update 5-24-07

Shibboleth just announced that they will add support for Cardspace/Infocard in the Shibboleth architecture. Kim Cameron's thoughts about it are here and Mike Jone's comments are here. This is a great development. The Shibboleth project has a great deal of respect and mind share in the identity community.

I'm not sure I agree that InfoCards authenticate the computer the user is on, and not the user.  I think that depends on whether they are combined with a challenge such as a one-time password.  I hope Jeff writes more about what he means by this.

Shibboleth adds CardSpace support

Here is news from Internet2 and Shibboleth, the open-source software for building multilateral federations that has become especially popular in the academic world (more information on Shibboleth here). 

ANN ARBOR, Mich. – May 23, 2007 –  Adding information card support to Shibboleth, the most widely-deployed federated authentication architecture, would enable interoperability with Windows CardSpace which provides critical support for secure user-centric authentication and identity information exchange for web-based applications. By enabling this interoperability, Microsoft and Internet2 aim to help users exchange personal identity information more safely and easily. In doing so, institutions can more effectively leverage their existing and future investments in their identity management solutions and build a closer, safer relationship with their users.

“As more and more companies and organizations make information materials and resources accessible online, the need for secure access solutions has become critical. We see information card technology like Microsoft's Windows CardSpace as a very important step forward in creating a ubiquitous Internet identity layer, which is a key goal of the Shibboleth project as well,” said RL “Bob” Morgan, security architect at the University of Washington and co-manager of the Shibboleth Project. “We appreciate Microsoft's leadership in helping to create an open environment for information card development and deployment, and are grateful for Microsoft support of Windows CardSpace work in Shibboleth.”

Shibboleth is a standards-based, open source middleware architecture providing both intra-domain and inter-domain single-sign on (SSO) capability. Used by over 20 million users worldwide within the research and higher education community, Shibboleth implements the OASIS Security Assertion Markup Language (SAML) standard specification, and is currently interoperable with Microsoft's Active Directory Federation Services (ADFS).

Both Shibboleth and Windows CardSpace provide the underlying mechanisms for institutions and individuals to share resources across organizational boundaries and to make informed authorization decisions for the access of protected online resources. This federated authentication model implemented by both Internet2 and Microsoft has proven to provide online resource providers and institutions with a solid platform for exchanging information in a highly secure and privacy-preserving manner. Once development is complete, sites using Windows CardSpace will have the ability to participate in the growing number of Shibboleth-based federations worldwide.

“The Internet2 Shibboleth project has been one of the leaders in bringing interoperable digital identity to the academic and research communities worldwide,” said Michael B. Jones, senior program manager for Identity Partnerships at Microsoft. “Shibboleth's support for information cards allows people in the Shibboleth federation to use the cards at sites participating in the Identity Metasystem, making the identities more valuable to both the issuers and to the individuals, as well as enhancing the user's control of their online interactions.”

I echo Mike's words.  Shibboleth is distinctly forward thinking in its approach, and has been the main crucible for refining the thinking (and practice) that enables multilateral federations like those needed to facilitate co-operation between universities. 

As Shibboleth federations continue to grow, so will the rewards for attacking them.  CardSpace, and other compatible Information Card selectors, will add resilience and phishing resistance while helping solve Shibboleth's “home site discovery” problem in a way that doesn't put control in the hands of evil sites posing as federation affiliates. 

For more details on what is at stake here, see this posting where I explain a similar vulnerability in OpenID.  SAML and the browser-based version of WS-Federation are also subject to these attacks, which become more probable as the technologies become more widely deployed.   

Ben Laurie on Selective Disclosure (Part 1)

Google's Ben Laurie has a new paper called Selective Disclosure in which he argues the importance of zero knowledge proofs and privacy-enhancing cryptography. I fully share his view of the importance of these technologies.

Everyone with a technical interest in identity should look at Credentica’s recently released SDK, called U-Prove. It holistically embodies the cryptographic breakthroughs of Stefan Brands.

There is also a competing system from IBM called IDEMIX, though it is not yet publicly available and I can't talk about it first-hand.

On his way toward explaining how these systems work, Ben takes the time to put forward his own Laws of Identity (“Let a thousand flowers bloom!”)  He is responding to my Fourth Law, which asserts the need for the Identity Metasystem to support both public identifiers (for example, my blogging address) and private ones (my account number with a given company, unknown to anyone but me and them).  He says:

“For an identity management system to be both useful and privacy preserving, there are three properties assertions must be able to have. They must be:

  • Verifiable: There’s often no point in making a statement unless the relying party has some way of checking it is true. Note that this isn’t always a requirement – I don’t have to prove my address is mine to Amazon, because its up to me where my goods get delivered. But I may have to prove I’m over 18 to get alcohol delivered.
  • Minimal: This is the privacy preserving bit – I want to tell the relying party the very least he needs to know. I shouldn’t have to reveal my date of birth, just prove I’m over 18 somehow.
  • Unlinkable: If the relying party or parties, or other actors in the system, can, either on their own or in collusion, link together my various assertions, then I’ve blown the minimality requirement out of the water.”

These are important things for the Identity Metasystem to support, and I make the same points in my own version of the laws. But I don't think these characteristics are the whole story – rather, they describe requirements for certain use cases.  However, there are other use cases, and it was the goal of the original Laws of Identity to embrace them as well.

For example, when I blog I want to use an identity that is linkable. I want anyone who is interested in my ideas to be able to talk about them with anyone else, and tell them how to get to my web site, which is – in the most literal sense of the word – a “linkable” characteristic of my identity.

And when accessing my bank account through the internet, I would rather like to ensure that the party withdrawing the money is tightly linked to a real-world person – hopefully me.

So we don't always want our identity to be unlinkable. We want unlinkability to be one of our options.

Similarly, I don't want every assertion I make to be verified by some bureaucratic process. I don't run around in the molecular world armed with official documents that I present to every Tom, Dick and Harry.  Again, I want verifiability to be one of my options, but not more than that. We need to be careful about what we wish for here. Requiring individuals to employ identities verified by third parties in contexts where there is no good reason for it is a slippery and dangerous slope. So I hope that's not what Ben has in mind.

When using a public identity (which I call “omnidirectional” because you share it with everyone) I may want to divulge more information than is necessary for some specific purpose. So even the notion of minimal disclosure doesn't apply within certain contexts and when public personas are involved.

Thus I take Ben's real point to be that an important and mainstream use case is one where verifiability, minimal disclosure AND unlinkability, should all be achievable at the same time.  This I agree with.

What strikes me as strange in Ben's document is this comment:

“Note a subtle but important difference between Kim’s laws and mine – he talks about identifiers whereas I talk about assertions. In an ideal world, assertions would not be identifiers; but it turns out that in practice they often are.”

I say “strange” because when you actually read the Laws of Identity this is what you will find:

We will begin by defining a digital identity as a set of claims made by one digital subject about itself or another digital subject. (page 4)

Is what I called a claim different from what Ben calls an assertion?  Well, on page 5 of the Laws, I wrote (citing the Oxford English Dictionary, well known to Ben):

A claim is, “…an assertion of the truth of something, typically one which is disputed or in doubt”.

Clearly I'm going a bit beyond Ben's concerns in that I remind the reader that assertions must be evaluated, not just made.  But in no way can I be said to confuse identifiers and digital identity.  In fact, I go on to give some examples which make my ideas in this regard perfectly clear.  (page 5). 

  • A claim could just convey an identifier – for example, that the subject’s student number is 490-525, or that the subject’s Windows name is REDMOND\kcameron. This is the way many existing identity systems work.
  • Another claim might assert that a subject knows a given key – and should be able to demonstrate this fact.
  • A set of claims might convey personally identifying information – name, address, date of birth and citizenship, for example.
  • A claim might simply propose that a subject is part of a certain group – for example, that she has an age less than 16.
  • And a claim might state that a subject has a certain capability – for example to place orders up to a certain limit, or modify a given file.

These examples demonstrate that there is no difference between my approach to claims in the Laws of Identity and that proposed recently by Ben.  Further examples abound: 

In proffering this definition, we recognize it does not jive with some widely held beliefs – for example that within a given context, identities have to be unique. (page 5)

Or:

In this scenario we actually do not want to employ unique individual identifiers as digital identities. (page 6)

Or:

It makes sense to employ a government issued digital identity when interacting with government services (a single overall identity neither implies nor prevents correlation of identifiers between individual government departments). (Page 9)

Now I know we're all busy.  I don't expect people to be familiar with my work.  But Ben explicitly cites what he calls my “famous laws” in a footnote, and calls out the “important difference” in our thinking as being that I'm concerned with identifiers, whereas he is concerned with assertions.  He's just wrong, as anyone who reads the Laws can see. 

The fact is, I like Ben, and I like a lot of his thinking.  I hope he reads my version of the laws before citing them again, and that he corrects his rendition of my thinking about identifiers and claims or assertions.  This seems doable since his paper is still a work in progress.

Pamela Dingle on multiple issuers

Some clear and advanced thinking from Pamela Dingle at Eternal Optimist:

Here is a simple and likely RP scenario that I’d like you to consider:

A given site wants to allow users to pay with either their Visa or their Mastercard information card. They do not, however, accept American Express. How should they create their security policy such that Visa and Mastercard managed cards are both highlighted in the Identity Selector if present, but also such that an American Express Card is grayed out and not clickable?

Would you all agree that this is a pretty important thing for a Relying Party to be able to implement? I think it’s important too, but I don’t see an easy way to actually accomplish it.

To my knowledge, there are two ways to choose what cards are highlighted and what cards are grayed out in the identity selector:

  • if a card’s issuer matches the value of the issuer parameter

  • if the entire set of required claim types are all present in a given card.

In the scenario above, the issuer parameter is a non-starter, because Windows CardSpace v1.0 only accepts a single issuer. And at this point in the identity metasystem, what WCS says, goes. I can specify Visa’s STS, or I can specify Mastercard’s STS, or I can choose not to specify an STS at all, but I cannot specify exactly two of them. Bottom line: as soon as I need to create a policy that lists more than one issuer, but less than all issuers, I cannot use the issuer statement.

So – that leaves us claims. Claims are great – when you can use what’s in them. In this case, however, the RP can’t work with claim values, only with claim types. In order to succeed in my scenario using claims, I would need to be able to specify a claim type that both Visa and Mastercard offer, but that AmEx doesn’t, in order to have the right cards show up and the wrong cards gray out. What exact claim type would that be? The only way I can see to architect such a thing is to have a commonly agreed upon but different claim type for every possible distinct combination of credit cards. Let’s say that there are 6 major credit card companies out there. How many permutations & combinations of claim types would be necessary to cover every single combination of 2,3,4, and 5 accepted cards, and how ugly would it be to add a new credit card?

It could theoretically be done. Identity Providers would have to start publishing two very separate types of claim types — contentless claim types that advertise capabilities, and content-rich claim types that would deliver actual data values. If you implement the capability claim types as constants and not as directory schema, it isn’t so bad — but the big problem is, it takes the ‘distributed’ out of this wonderful distributed system.

Unless things change (or unless I’m proven wrong, maybe I’m just missing some answers and need to be educated), here is what I fear will happen: users would go to a Relying Party Site, only to be presented with an HTML “menu” of supported managed card providers. They would then click on the card provider logo, and an HTML object would be invoked which has an issuer tailored to that single provider. Is this what we want to have happen?

If it does happen, I can see all sorts of fallout:

  • Common claim types are no longer needed to ensure the user picks the right card. This is good.

  • Every RP has to alter HTML to support a new Identity Provider. This is bad, or at least worse than adding a url to an allow or deny list.

  • The ability for a Relying Party to require the same claims from every Identity Provider becomes damaged. This is bad. Of course, with issuer in the state it is in, I would say that no matter what, this is already the case.

  • The system is more distributed, but MUCH less consistent for the user. This is bad.

  • It opens the door for the more established Identity Providers to set arbitrary rules on what attributes “must” be asked for in order to interoperate, forcing Relying Parties to embed different code for each provider. This is bad.

Of course, all of this hinges on how important the initial card presentation ceremony becomes to the world. Remember that we are not talking about the RP’s ability to accept or reject a card once it has been selected. We are only talking about how to get the most user-friendly initial display of highlighted or grayed out cards when the selector opens. Maybe this small part of the information card ceremony won’t end up being that important — but I predict that it will. If I could have have any kind of solution to the problem, it would be the ability not just to list multiple issuers, but to apply Boolean logic to the list, so that I could represent ideas like “every issuer except these two”.

Kim, Mike, what can we do? Is this as big a problem as I’ve made it out to be, or am I just whining about something inconsequential? What is your vision of how my scenario could be implemented? Can this be solved with a few best practices, or do we need to change the way that information card RP security policies can be specified?

Pam's thinking is unassailable.  The problems she outlines are issues we just didn't have time to solve in version 1.0 of CardSpace. 

We were aware of them, but wanted to get the first round of our technology “out there” so everyone could start doing proofs of concept and implementations that would help clarify the right approaches.  I think in practice we'll have time to fix this before people anyone really “feels” it.  Not all credit card providers will be supporting information cards at once.  Meanwhile we'll be pumping out more advanced versions of CardSpace that address the issue.  

The same problems Pam describes with respect to issuers apply with respect to RP support for multiple token types (e.g. SAML tokens plus OpenID tokens).  Currently we can address this by accepting “any” token type, and that will get us by for a while, but ultimately we will need to be able to specify rich combinations.

WS-SecurityPolicy is powerful enough to express boolean logic, so theoretically the relying party can publish metadata that has all the capabilities Pam calls for.  For example, you can say you will accept American Express AND Visa as issuers but not Diner's Club.  You can also require different claim types from different issuers.  So the architecture is adequate to the problems.  

So given that the architecture is right, it represents an opportunity for our competitors…  And we ourselves are working really hard to solve this problem in our next version – before it anyone feels the pain.

Conciously false technology claims

My lawyer friends all know I am “legally challenged” – so don't take anything I say about legal issues as representing any particular expertise. 

But on the news today I saw a story about a drug manufacturer showing the consequences of making false technical claims like those I objected to here in other walks of life: 

NEW YORK (CNNMoney.com) — The maker of OxyContin, Purdue Pharma LP, agreed Thursday to a $600 million penalty as part of a plea deal with the Justice Department on a felony charge of misleading and defrauding physicians and consumers, the government said.

Three of the company's executives, including its CEO, general counsel and former chief medical officer, have separately agreed to pay $34.5 million in penalties. The company and the three men appeared in federal court Thursday to plead guilty.

The company also agreed to subject itself to independent monitoring and a remedial action program.

“Purdue … acknolwedged that it illegally marketed and promoted OxyContin by falsely claiming that OxyContin was less addictive, less subject to abuse and diversion, and less likely to cause withdrawal symptoms than other pain medications – all in an effort to maximize its profits,” said U.S. Attorney John Brownlee.

There should be accountability and penalties for those who consciously mislead people like the Marlin County school board, convincing them there is no risk to privacy by preying on their inability to understand technical issues.  It should be mandatory, when selling technology with potential privacy implications, to explain the threats and mitigations in an objective and public way.

Age and identity verification in Second Life

Via Dennis Hamilton, a pointer to a new experiment at Second Life:

We will shortly begin beta testing an age and identity verification system, which will allow Residents to provide a one-time proof of identity (such as a driver’s license, passport or ID card) and have that identity verified in a matter of moments.

Second Life has always been restricted to those over 18. All Residents personally assert their age on registration. When we receive reports of underage Residents in Second Life, we close their account until they provide us with proof of age. This system works well, but as the community grows and the attractions of Second Life become more widely known, we’ve decided to add an additional layer of protection.

Once the age verification system is in place, only those Residents with verified age will be able to access adult content in Mature areas. Any Resident wishing to access adult content will have to prove they are over 18 in real life.We have created Teen Second Life for minors under the age of 18. Access to TSL by adults is prohibited, with minors not allowed into the rest of Second Life.

For their part, land owners will be required to flag their land as ‘adult’ if it contains adult content using the estate and land management tools provided to landowners. This flag will protect landowners from displaying inappropriate content to underage users who may have entered Second Life. Landowners are morally and legally responsible for the content displayed and the behavior taking place on their land. The identity verification system gives them new tools to ensure any adult content is only available to adults over 18 because unverified avatars will not have access to land flagged as containing adult content.

We hope you’ll agree that the small inconvenience of doing this once is far outweighed by the benefits of protecting minors from inappropriate content. Further, this system will assist landowners in engaging in lawful businesses.

The verification system will be run by a third party specializing in age and identity authentication. No personally identifying information will be stored by them or by Linden Lab, including date of birth, unless the Resident chooses to do so. Those who wish to be verified, but remain anonymous, are free to do so.

(Continues here…)

The idea of presenting a passport to get into an imaginary adult establishment strikes me as nutso.  I must be missing a gene.  It is certainly a conundrum, this virtual world. 

I think that rather than adopting this one-off inspector approach, outfits like Second Life and all the other big web sites should get together to accept registration claims from whatever identity providers would fully guarantee both accuracy and the anonymity of their users.  Information Cards combined with the anonymous credential technology developed by people like Stefan Brands would provide the ideal solution.

WS-Federation OASIS TC

I'll begin by quoting from a piece by Paul Madsen after the OASIS announcement of a new working group to drive WS-Federation towards standardization.  Paul writes: 

“James McGovern predicts:

‘I humbly predict that WS-Federation will become more important than SAML within the next two years and will invalidate all the hard work already done by the Liberty Alliance.’

“I guess it's over. I have to admit that I'm disappointed and, to be honest, even surprised.

“I actually thought things were going well, you know, lots of adoption, encouraging signs of convergence, important new functionality etc.

“As for the New Jersey Devils, it seems that the Liberty Alliance's playoff run is over. I'll be emptying my locker and signing autographs this afternoon before spending the summer golfing.”

Like Paul, I'm surprised, if not so inspired to irony, by James’ comment. 

I do agree that WS-Federation will gain a lot of traction.  But I absolutely disagree that it will “will invalidate all the hard work already done by the Liberty Alliance.” 

Liberty has contributed deeply to understanding a whole series of use cases and requirements, and the protocols, formats and concepts proposed by the SAML working groups have been an important step forward for all of us involved with identity.  Nothing about WS-Federation invalidates this work.

On the other hand, technology doesn't stand still.  Think back to the days when SAML was first posited as an alternative to LDAP authentication.  Those of us involved in LDAP from the very beginning didn't for one minute take LDAP as the end of all thinking about attributes and identity.   Ask LDAP guru Mark Wahl, or Bob “RL” Morgan or Keith Hazelton – people deeply involved in Kerberos and LDAP but just as willing to embrace new technologies like SAML as meeting new use cases.

Just as SAML broke new ground, WS-Federation is intended to address a number of things that people working in Web Services want better defined to facilitate interoperation using WS-Security and WS-Trust. 

These protocols hadn't even been invented when SAML evolved.  The idea of claims transformation is the most important technical advance in distributed computing for at least a decade.  It is so powerful that it wasn't even fully understood until we began to build things with it.  So how can anyone expect SAML to deal in an optimal way with the issues that ultimately emerged?  This doesn't detract from SAML's successes.  That's not how software engineering works.

WS-Federation will provide new options for people who want to build on the web services architecture, evolving their current web technology in an incremental way to be consistent with that architecture.  To do this, no one will have to throw out their existing SAML deployments.  Many of the SAML producers will include support for WS-Federation so that interconnectivity will be a given.

A lot of WS-Federation editorial work has been done by my friend DES (Don Schmidt).  This guy has paid his dues – triple dues – and works from a deep experience in security.  After some badgering he has just started to blog his ideas.  Here's part of how he explains his goals: 

WS-Federation enables development and deployment of advanced federation services (e.g. Authentication, Authorization, Attribute and Pseudonym Services) as special purpose variations of the WS-Trust STS claim transformation model.  Managing, discovering and accessing such services can be simplified when they are all based on a common processing model and speak the same protocol. Further, reusing an established processing model and protocol can simplify the threat model for implementers and should lead to more robust code.

Customers have indicated that manually configuring federation trusts – particularly exchanging signing keys and specifying service endpoints and access policies – is an onerous process when they have many partners. WS-Federation defines a Federation Metadata format to identify services, including the communication and security policies which must be satisfied for accessing them. This enables much of the configuration to be automated.

Another significant benefit of WS-Federation is improved security through “automated de-provisioning” of external user access. If a Relying Party issues local accounts for external users from its partners, it may not immediately learn when those users have changed responsibilities or been terminated. Such accounts could be misused to obtain unauthorized access. WS-Federation enables a Federated Identity relationship wherein a user can no longer access a partner’s resources as soon as he is unable to obtain a valid security token from his own organization.

Microsoft is actually pretty typical of many other companies in that it will have to support a whole spectrum of deployments reaching from simple, restful apps at one end to transactionally guranteed high security applications at the other.  The ability to support the whole spectrum consistently is the key.

We don't want to build two parallel infrastructures in order to do this.  We don't want to deploy everything twice.  Test everything twice.  Secure everything twice.   Does anyone? 

So we need a technology that takes everything learned while elaborating SAML – plus new features – and allows them to be composed and managed within the WS framework as well as used in conventional web sites. That's what I understand this TC to be about.

It remains a personal hope that those who have been involved with SAML will adopt this larger goal as part of what needs to be achieved.  That really will make convergence possible.

And I also expect everyone to give them credit for all they have done, which will not be lost if WS-Federation continues to gain momentum, but will rather be extended.

Information Card Contest

I was still reeling from the latest chicken pictures posted by James McGovern when I stumbled onto news of a contest put together by my colleague Richard Turner. 

James was complaining that the contest would slow down adoption in his case since it would break corporate policy to accept a prize.  I added a comment to his blog saying I would try to figure out a way that someone who could not accept the prize could make a charitable donation instead. 

But I didn't know what the prizes were until I read the original posting by Richard:

Identifying yourself online is becoming increasingly difficult and dangerous. Most people who use the web have to maintain several usernames and passwords and have to remember which usernames and passwords to use at the various sites they use.

While usernames and passwords are a growing frustration to most users, this problem is dwarfed by the growing threat of phishing and other forms of malware and identity-related attack.

Follow the wrong link and try to sign-in to a malicious site masquerading as, for example, your bank, and you run the very real risk of suffering considerable loss. These potential losses may be financial but may also impact your reputation (e.g. credit score) that may take years to repair.

Microsoft, along with many partners in the IT Industry, is building a suite of technologies to help combat the phishing issue, whilst making it easier for users to authenticate safely online. Technologies such as Windows CardSpace enable users to identify themselves by presenting cryptographically strong identity tokens (represented visually as information cards) to supporting websites.

To help fuel the growth of sites supporting Information Cards, Microsoft is announcing a competition that is open to every website owner, regardless of your web platform of choice. We hope you'll join us in helping to protect your user's identities from abuse and make it easier for your users to sign-in to your sites! 

How to enter

  • Add sign-up and sign-in support for Windows CardSpace to your website
  • Email the following to identity@microsoft.com
    • Details of your site
    • Your details
    • Complete this statement: “We added support for information cards to our site because …”
  • All entries will be judged by the CardSpace product team and winners announced on August 17, 2007. The winner will be notified by email.

The prizes

  • Grand Prize:
    • 1 Round-trip ticket (from and to a single location within the United States)
    • Overnight accommodation in a hotel near Microsoft Campus
    • Meet the team – spend a day with various members of Microsoft's Federated Identity team
    • Dinner with Kim Cameron
  • Second prize:
    • XBox 360 Elite Games Console
  • Third prize:
    • Zune music player

[Please note that due to international gaming laws we are only able to offer these prizes to US Residents and that any taxes incurred from receiving a prize is the sole responsibility of the prize winner(s).]

Adding support for Windows CardSpace to your site

  • The following resources will be indispensible in guiding you how to add support to your website:
  • If you have technical issues, please post questions to the Windows CardSpace discussion forum on MSDN – we'll be monitoring this forum closely and responding as quickly as we can. Note – if you contact us directly with support requests and your request is generic in nature, we'll ask you to post your question to the forum. This is the help others who may be experiencing the same issue as you and so that we can better manage potential support issues.

Anyway, that sounds like a lot of fun, and I'll make sure the winner gets a really incredible evening at one of the top restaurants in the region. 

And as for James, now I know what the prize is, if he wins we can just make it a working dinner at the local pub, taking on the role of Information Cards in the enterprise environment and all the other things I'd like to discuss with him from a purely business point of view.

QT and the perimeter

Jeff Bohren, The Identity Management Expert at TalkBMC, makes a great point about what laptops mean and hits gold with Quantum Tunneling.

Kim Cameron has another interesting entry on Deperimeterization here. All of this got me to thinking about another aspect of perimeter security, and that is network location. People tend to think of computers as being logically located inside or outside of the security perimeter. Or more specifically people without laptops tend to think that. If you have a laptop, you quickly realize that you flip-flop between the state of being in and out of the perimeter on a daily basis, or more frequently is you use VPN.

I like the analogy of Quantum Tunneling (QT). One moment your laptop is outside the perimeter, the next it’s magically in. Then out again. QT in, QT out. Of course any malware your laptop picks up outside the perimeter will be carried in on the next trip in. This should really be the nail in the coffin of perimeter security thinking, but unfortunately it isn’t.

The QT analogy came to me because I have been reading Ilium by Dan Simmons (author of the Hyperion series). This SF novel combines The Illiad, QT, Greek Gods, a mostly depopulated Earth, a terraformed Mars, Little Green Men, and Jovian Cyborg buddies (one who likes Shakespeare and one who like Proust). I’m not done yet, so it will be interesting to see if Simmons can pull it all together at the end.

Here is the identity tie in. In Simmon’s future Earth, the few remaining inhabitants can teleport from place to place. It turns out that peoples bodies aren’t actually teleported. The body and brain waves are scanned at origin and that information is stored in a central computer. The body, thoughts, and clothing are reconstituted at the destination based on that information.

Teleportation of identity! Fascinating.

Jeff has definitely got it.