For this year's Balisage in Montreal, we (R. Dingwell, A. Gregorowicz, H. Sleeper, and myself) have been accepted as a late-breaking proposal for our work on hData, which addresses some problems that are currently plaguing electronic health records. Our session is scheduled on Thursday at 11:00am. This is the abstract:

Title: hData - A Simplified Approach to Health Data Exchange

Interoperability issues have limited the expected benefits of Electronic Health Record (EHR) systems. Ideally, the medical history of a patient is recorded in a set of digital continuity of care documents which are securely available to the patient and their care providers on demand. The history of continuity of care standards includes multiple standards organizations, differing goals, and ongoing efforts to reconcile the various specifications. Existing standards define a format that is too complex for exchanging continuity of care information effectively. We propose hData, a simplified XML framework to describe health information. hData addresses the challenges of the current HL7 Continuity of Care Document format and is explicitly designed for extensibility to address health information exchange needs, in general. hData applies established best practices for XML document architectures to the vertical health domain, which has experienced significant XML-based interoperability issues.

As you might imagine, we will have to say a few things about identity, access, and privacy management for electronic health records, as well. Looking forward to seeing you there.

tags: balisageConference09 EHR HIT health care health records hData

tinyarro.ws: http://➡.ws/榾 (wood chip)

The time has come to start working on comprehensive identity convergence ... with Venngeance:

Trust is one of those concepts in IdM that are hard to define or measure, yet are at the basis of most of our transactions. There are a few different ways to look at trust or capture its essence, including reputation systems, assurance frameworks, and similar solutions. At the end of the day, however, it most often comes down to this:

Basic law of trust (BLT): Alice will only trust Bob in a transaction, if the benefits outweigh the perceived risk plus her personal margin of safety.

Sometimes there are situations where we MUST trust another party (through legal requirements or lack of other options), but these can be seen as special cases.  

Now, applying the BLT, one has to manage both parts of the equation: risk (including the safety margin) and benefits. The benefits can be rather manifold, and cover all aspects of internet usage: services, purchases, personal enjoyment.

The risk on the other side can also fall into different categories: financial, reputation, legal, etc. In many cases the financial risks are most prominent: for example, when I buy some book on the internet, how can I be assured that (i) I really get the book, and (ii) my financial and personal information (shipping address) is safe and not misused. Obviously, I do have to trust the retailer and his ecosystem of partners (payment provider, shipping company, etc.) to perform the requested services to my satisfaction.

Reputation of the retailer does play a critical role: if I personally know people that had a good shopping experience at the retailer, and in addition know that there are (apparently?!) many good review by people I do not know, I am tempted to assume that the risk is not too big. At the end of the day however, it really comes down to this:

Financial trust - sue and collect: Alice will only trust Bob, if - in case something goes wrong - Alice has legal recourse and can expect Bob being able to pay sufficient damages.

I am not 100% sure if this is really at the foundation of trust in commercial transactions, but it seems to be at least one important factor. Obviously this is not a very optimistic point of view, hence the title of the blog entry.

When I read Larry Seltzer's piece on H.R. S 773 IS, I fell into a constant nod about the issues he raised. In addition, I have two more:

SEC. 11 (a): Lofty goals, but these seem rather obvious, since they have been at the heart of any computer security research for a rather long time.

SEC. 14: This sections empowers the Secretary of Commerce with very far reaching powers, especially since 'critical infrastructure' is so woefully underspecified.

In general, I am very unhappy with the bill's vagueness and lack of definition, especially since there are enough provisions (such as SEC. 17 - see Larry's comments) that can significantly impact the civil liberties of all U.S. persons. The intent of the bill seems honest enough, but in order for this to not backfire, a lot more work needs to go into a more robust draft.

The excellent article "Security and Data Sharing" by Mark Richard and Leslie Lebl points to a few very important ramifications that the less than ideal current data sharing situation with the E.U. brings and what the ratification of the horrible Lisbon Treaty would mean for the future of international security cooperation. The article also mentions the potential positive effects of the U.S.-E.U. MLAT framework.

What really caught my attention, though, was the authors' regard for the supposedly high European standards for data protection and privacy. They are correct in assesing that the implementation of the Privacy Directive varies within the various member countries, with countries like Spain or some of the relatively new members not paying to much attention to privacy issues at all. At the same time, Germany is portrayed as having a very high standard of privacy and PII data protection. Unfortunately, this is not at all the case:

While many middle-aged Germans do remember the strong controversy about the 1983 census (which was relatively harmless in itself) and the German surpreme court even recently emphasized a basic right to privacy protection, the implementation in the real world are a far cry from the supposed nirvana of "information self-determination".

First, it seems prudent to make a fundamental difference between the rights of the German population viz-a-viz the private sector and government. When dealing with private entities, Germans do actually enjoy a fairly high level of control over what information someone might legally store about them, how it is used, and when it has to be amended or destroyed. Reality paints a somewhat different picture, though. Over the last few months, a number of scandals have surfaced, cutting across the entire spectrum of privacy invasions: large companies have spied on their employees and customers using hidden cameras or collected and used profile data without their knowledge. Beyond that, a number of shady address collection agencies have sold millions of records including financial information. In some cases, significant sums of money were misappropriated by thieves that automatically drafted funds from bank customers through the ACH. Obviously, these criminal acts (at least those that have surfaced) are being investigated, and hopefully the judical system will be able to mediate the harm done. 

The situation with respect to government privacy intrusion is much more dire, though, and it would be fair to state that any resident in the U.S. enjoys a much higher level of government intrusion that any German ever had. For starters, every German (in fact, European) is now issued at birth an 11-digit taxpayer identification number that is unique and valid over their entire life. One might argue that the SSN is very similar in this respect, but there are two significant differences: (i) no U.S. resident is *legally required* to obtain a SSN and (ii) the FTC and the other government agencies have realized the ID-Theft threat that such an identifier poses and there is active work to limit the use of SSNs.

But the issues go far beyond unqiue identifiers: every resident of Germany is legally required to notify city hall within 30 days if they move  - either within their street or across the country. Interestingly enough, this data is readily available to any interested private company, and some 400+ towns and cities have made some nice extra cash by selling off these lists. In addition, all residents are required to own a national ID-card, which will soon contain their digital photo, fingerprint, and a practical RFID chip for easy data skimming. 

This list goes on, and includes absurd stories of mandatory public broadcast fees (which are sometimes collected from residents that have been dead for more than 400 years - but, being Germany, they do have to pay.. or at least the church where they are burried). At the end of the day, the de-facto privacy protection in Germany is not at all better than e.g. in the U.S., where at least a strong vertical and horizontal division of powers and an active community prevents a centralization that has become so typical for Europe.

Through Ian Fletcher of Burton: Peter Fleischer of Google is now facing criminal charges for failing to prevent the publication of a defamatory video on Google's video site - taking it down after 24 hours was not sufficient. While this is a somewhat extreme case, I fully expect an increasing number of civil and criminal cases filed against companies and government agencies for failing to protect the privacy of data principals: In the U.S. the efforts to standardize patient's electronic health records and federate access to this data will invriably lead to some cases of unauthorized disclosure. Europe has already had a decent share of privacy violations lately, but the effects have so far been manageable.

Going forward we as a society need to coordinate data access much better than we have so far, thus it starts making sense to star talking about privacy management as a separate discipline in corporate IT and process management. Privacy management is obviously closely related to information and identity management, but has a strong legal/regulatory aspect. Especially the lack of any harmonization of global privacy frameworks is a constant threat to globally operating companies. Some of these aspects will be discussed at the next Liberty Plenary meeting. 

tags: privacy google privacy management liberty alliance

Jeff thinks that my term describing the privacy situation in Europe is a little harsh. I cannot blame him, since the Europeans, and especially Germany has been working hard on presenting themselves as the global guardians of privacy. And, true enough, the rights that a European citizen has viz-a-viz private sector companies is considerable. Also, Germany's supreme court confirmed on multiple occasions that there is a "Informationelles Selbstbestimmungsrecht" (right to information self-determination).

Yet, when it comes to the government or its associated entities prying into peoples lives, all bets are off:

• Go to the U.K. and try to not be captured on a surveillance camera. Anywhere.

• Try renting an apartment or buying a condo in Germany. Within 30 days you must submit a form to city hall declaring who you are, where you lived before, and who else is living in your home. This data is automatically shared with semi-private organizations such as the collection agency for public broadcast fees, but also with anyone walking up to city hall that deems you a debtor.

• There is a EU directive that establishes a community-wide unique tax ID number far all citizens and residents of all ages. This number is permanent, and must be shared with employers, banks, and - potentially - insurance companies. Sounds familiar?

• All trucks in Germany are required to use a satellite-based tracking system to determine tolls for using the Autobahn. This data is collected by a private-sector consortium on behalf of the government, and there are a number of politicians suggesting this for all vehicles.

• Finally, Germany's "Personalausweis" (national ID card) is mandatory for anyone over 16. So far, city hall was managing this data, but since there are preparing to put biometrics on this one, there will soon be a comprehensive federal database of all citizens of Germany over 16, complete with digitized photo, fingerprints, and later iris scans.

The list could go on and on - I am sure that Robin has a lot to add to this list. Needless to say that there have been numerous occasions where data collected by government agencies has been "lost", stolen, or otherwise compromised. While we are talking about theft: Germany has paid more than EUR 5 Mio for stolen data about alleged tax evaders.

So yes, my choice of words might have been harsh, but unfortunately quite justified.

tags: privacy europe germany

The DHS Data Privacy and Integrity Advisory Committee of the Privacy Office of DHS has sent a letter to the new Secretary of Homeland Security, Janet Napolitano, making some recommendations for the adjustment of the way the department deals with privacy policy and issues. Some of the more notable ones include:

• Compartment Privacy Officers

• Data Governance

• Interoperability and Data Integrity

• Overhaul of the 1974 Privacy Act

• Independence of the Privacy Office from the rest of the organization

These are excellent suggestions, especially when applying them as a whole: having a compartment Privacy Officer, that can act independently of the rest of the organization has the potential of channeling the efforts of the department into the right direction. Improved data governance, integrity, and better interoperability should really be on the agenda of the CIO as well, but especially in the context of E-Verify or Border control these issues also gain a privacy facet.

Overall, this letter should be a recommendation not only to the DHS, but government and private organizations in general (mutates mutandis). Major privacy invasions (as we have recently witnessed them en force in Germany) can only be avoided if privacy compliance is considered as critical to an organizations success as any other good governance principle.

tags: privacy dhs

It took a long time, but it seems that the time for an older idea of mine has come: Jeff Hodges is reporting on a report he prepared for the MIT Kerberos group to explore the use of SAML tokens in traditional security systems. A while ago, I was exploring a similar idea - then with Eve and Nico - on how to use SAML attribute and bearer token in the context of the GSS-API. 

The ideas and concepts we had then would still seem valid to me, although a lot of things have moved on since then. I will definitively follow this, if only from a distance.

tags: saml gss-api kerberos

Oh well, I finally sat down and took the time to convert my aging main web site into something more dynamic. Since my - overall - quite reliable hoster gives me free PHP5 and MySQL databases, I took a closer look at Drupal, given its overall support, ease of use and add-on module availability. My first impressions are quite good: it was easy to get up and does not seem to be too hard to administer. Converting my exising HTML went well, although the default editor (or more specifically: the Drupal filters) have a tendency to get in the way at the beginning.

Now, one thing I will probably spend a little time on over the next few weeks (time permitting - haha), is to develop a somewhat more reasonable authentication scheme for my various web properties. I have a happy collection of PHP apps, this .NET based blog, and also some custom Java apps. So far there is really no identity management in place; a fact that has been a sore for a while. A simple SSO authentication scheme across these difference platforms is a panacea, but it should not be to difficult to achieve. I am looking actively into using Oauth or SAML as the token format, and a simple RESTful transport.

tags: web site identity saml oauth rest

Times are changing, and people have to change with it. Doh - another pearl of obvious wisdom, but there is an interesting application to the work life: while regular employment might change rather abruptly, business and community relationships usually do not. So while you might no longer be working for a particular company (say, Sun, for example), you would still be interested in continuing your work in a particular area of interest (say, identity, for example).

In this spirit, I decided to join the Liberty Alliance as an individual member. The new structure of the organization, combined with a reasonable fee schedule allows me to continue my formal relationship with one of the more comprehensive identity consortia currently in existence. While I have not yet quite made up my mind on how this engagement will be, I know that there are a number of current project in TEG and IAEG that stir my interest.

One of the most interesting developments in Liberty right now is the realization that a RESTful approach is quite necessary to extend from an enterprise-centric identity management system to one that can scale up to the needs of health care providers and governments. The need for a lightweight IdM and federation framework is indisputable, and the GSA and Internet2 have already demonstrated that the existing feature set in SAML2 is sufficient to build a meaningful federation. However, it will take the legal and business rules framework of the IAF and related efforts to extend these technologies into the realm of social networking and eGovernment where you cannot rely on having a mutual trusted partner in identity.

So, going forward, it will be a lot of fun to dabble with the same technology, only now from a slightly (or not so slightly) different angle. 

tags: project liberty identity rest

The workshop on Open eGovernment is starting right now. Here is my slide deck, for all that might be interested:

MIT MediaLabs - Open Identity Archtecture.pdf (1.01 MB)

Soon after this is complete, the entire workshop will be posted on the MediaLab webpage - please stay tuned for the link.

tags: identity management policy

As part of the new U.S. administration's BigDialog and Open Government technology agenda, the CommunityCount web forum is polling for issues that are relevant to the identity management community. If you want to make you voice heard with the transition team and the next CTO and science office staff go here, put in your questions and issues, and vote on the others.

Here is my contribution - please vote.

tags: identity management policy

    I love foundational discussions - they always have the potential to fundamentally change my world-view, which is quite stimulating.

    Radovan picked up on my little piece on reputation. In particular he suggests that the question "What attributes should be influenced by reputation and what should not?" does not make any sense.

    I fully agree with this statement, but not necessarily with all conclusions that Radovan draws. As I see it, the question is not what attributes of an entity should be influenced by reputation, but much more about what attributes can be reasonably approximated by a mean-value approach such as reputation.

    In Radovan's example, the height of a given person can be precisely determined (up to an error margin, that is part of that measurement). The result of such a measurement--as long as it is reproducible--is the objective value of the attribute "height". It does not make any sense to attach a reputation to this value. But you can attach a reputation/"credibility score"/whatever to the measurement process (this is typically done through the specification of the error margin), or the faithfulness of storing this information in a given storage system (e.g. through the reliability score of this provider, determined by averaging over the subjective reliability score given to the storage system by its customers/clients). The aggregate "reputation" of this process (measuring, recording, storing, reproducing) can then be used to calculate the "reputation" of you saying that I am 147 cm tall.

    But--and this is important: your statement about my height (or the aggregate statement of the community about my height) does not influence the fact (if you want to use this hopelessly overloaded term) that I am 187cm tall.

    This is fundamentally different from what might happen with other attributes: for example, let us look at my "reputation for drawing aesthetically pleasing pictures". While I ( or my daughter) might be convinced that I have a rather high score for this attribute, the rest of the world might beg to differ. My community-wide^[1] reputation as a gifted painter could thus be much lower. Note that I do not have any reasonable recourse: there is (fortunately) no final authority, or repoducible process that can determine a definite value for this particular attribute.

    Nevertheless, for such non-CFD, mean-value attributes you still face the same issues that you do face for objective attributes: there is the change of recording or storage failure, and thus other factors that might ultimately determine the reliability of a "reputation as painter" score I might have.

[1] Note that at this point it becomes very important to define the correct domain of your mean-value process, i.e. you have to fix an ensemble.

    Paul proposed a conjecture regarding the validity of using reputation systems in the context of identity systems. This (and some discussion on the IDGang list) inspired me to dig again through some of my notes regarding the ontology of physical reality (and thus--by extension--quantum theory).

    My personal position in the discussion on the most sensible approach to physial ontology was always firmly rooted in the realist corner: I completely reject positivism and--mostly-- empiricism on fundamental principle. There is no doubt in my mind that there is an objective physical reality, independent of human (or any other) observer^[1].

Reputation in information systems

    Now, a reputation scheme can easily be interpreted as mechanism to determine the value of an entity's attribute by averaging over the subjective values of that particular attribute, as seen by an ensemble of parties interacting with the entity in question. So, for example, to determine the "trustworthiness in business transactions" of user A of an auctioning site, one can average over the subjective opinion of business partners of user A on his trustworthiness.

    This approach is valid, and as many social (or even business) sites indicate very useful. It can be applied reasonably well to attributes of an entity that are either non-counterfactual definite (i.e. completely subjective), or not measurable by an objective and reproducible measurement approach.

    "Trustworthiness" is a good example for a subjective attribute, and credit-worthiness of a company or individual might be an attribute of the later type: while the fundamentals of a company determine its ability to shoulder a certain about of debt without collapsing, there is (to my knowledge) no definite algorithm to compute a simple "creditworthiness" attribute. However, the averaging over the credit ratings from different rating agencies (i.e. a kind of "credit reputation") is normally a good approximation of this attribute^[2].

    However, there are some attributes that cannot be averaged over: those attributes are counterfactual definite, i.e. objective and can be measured by a repoducible mechanism. A good example for such an attribute is my physical height,  my employment status with a given company, or my gender. All of these might change in time, but at a given point in time, they can be easily determined and have an objective value--even if nobody measures it. Applying a mean-value approach to these does not make any sense.

    One might interject, that for such a counterfactualy definite attribute there might be a different perception of its value with other entities. For example, while my actual height is 187cm (~ 6' 1"), some people might think that I am taller or shorter.  Now, my actual height does not change because a number of people are thinking so. It is my perceived height that changes and this attribute is entirely different from the former.

    So, in the end it is very important to evaluate carefully if a given attribute of an entity in an information system lends itself to be used in the context of reputation systems. In some specific cases this does make sense, but in others it is entirely pointless.

[1] Yet, while realism is vital to my world view, I am much more inclined to abandon local reality than counterfactual definiteness.

[2] The current financial quagmire is an example of how such a reputation system can fail.

    Amazingly enough, it took less than 24 hours to see the first massive privacy issues flaring up with Google Chrome. In a CNET interview, Peter Eckersley of the EFF says:

"We're worried that Chrome will be another giant conveyer belt moving private information about our use of the Web into Google's data vaults," Eckersley said. "Google already knows far too much about what everybody is thinking at any given moment.

    Now this is a total surprise, is it not? Not only can Google read all your mail, knows what you are looking for on the web, and has your financial information through Googlc Checkout or Adsense. With the Omnibox (or the mysterious "one or more unique application numbers"), they now also see all the places you go to -- on the internet and any possible intranets.

    Now, I do not know exactly how this will play out legally, but as far as I am concerned, the internal structure of an Intranet is usally some I'd rather not expose to outsiders. Beyond privacy concerns, there are clear security and intrusion concerns, and allowing Google to obtain this data for free and without any binding contract between Google and my company does not seem very prudent. If I had any say, I would strangle recommend to prohibit the use of Chrome in any enterprise environment. This should obviously extend to government agencies, and among them law enforcement and military. How embarrassing would it be, if--by honest mistake--the DNS or CA infrastructure of the combat command and control systems of say, the Airforce or the CIA would suddenly appear on a Google search result.

    Do not get me wrong: I do like Open Source, and adding competition to the market is always a good thing. I simply see the ugly face of monopoly lurking around the corner, and this time it also has a big file on any internet user. This is a little too much power in the hands of a single entity. If Google was part of a government, people would be a lot less eager to submit their most private data (with the exception of Germany, of course--there it works the other way round).

tags: google chrome privacy

  Last year we announced an experiment at Sun: in order to gather more information about the operational characteristics of "user-centric" identity technologies, we decided to roll out an OpenID provider for Sun employees. This OpenID provider was intended to be used by Sun employees for personal usage at various OpenID sites that have been popping up at some places.

  This experiment involved various parts of the company, including field people, products folks, the security team, and our Chief Privacy Officer. We negotiated a number of requirements for our experiment: employee privacy must be maintained at all times, the system must not interfere with any other Sun authentication or business system, etc. All this was quite achievable and we passed the--albeit lax, since it was an experiment--security and privacy reviews, the focus of which was the protection of Sun employees and property.

  The weakness in Debian-generated certificates and the recent DNS cache poisoning attack vector resulted in a triple whammy: weak certificates, broken DNS, weak protocol. After Ben's report last week, we revisited the current design of the service and came up with a few recommendations. Mark Wilcox notes that my list could be hard to follow, especially for non-technical users. To some extend^[1] I do agree with him, so we decided to take additional steps on our end to improve security:

  The very core of these changes lies in the idea that we are introducing HTTPS based OpenIDs for our users. In OpenID 1 and 2, a RP normalizes any identifier without scheme prefix into an unsecured HTTP based identifier. Only a prefixing the OpenID identifier with the https:// scheme will result in discovery over an TLS secured transport channel. This looks a lot "geekier" than the somewhat more appealing "naked" OpenID identifiers, but as a result of this change, the lookup will now be handled completely over server-authenticated channels. 

  In order to make this approach useful, we would need the cooperation of OpenID RPs: in the current specs, http://openid.sun.com/user and https://openid.sun.com/user are two separate entities, which--in my opinion--makes no sense. If RPs would start recognizing these two identifiers as the same entity, it would help improve the security of the OpenID protocol in a quite significant way, since users could easily migrate from the broken insecure HTTP discovery protocol over to the somewhat more secure HTTPS transport.

  Obviously, this cannot address the key-reandomness weakness, but then ... only time can. Meanwhile we have to rely on CRLs and OSCP checking for certificate revocation.

  UPDATE: The approach outlined above might be criticized for equating two URI that are not equivalent (https://... and http://...). I appreciate this from a principal point of view, but extreme time require extreme measures .

  A reasonable way to address the potential security implication for current https://.. identifiers would be for the RP to perform a one-time security upgrade: assuming that the RP recognizes a particular claimed_id e.g. http://openid.sun.com/user. Whenever there is a login with the same identifier over HTTPS (i.e. claimed_id is https://openid.sun.com/user in the example), the RP can 'upgrade' the account to an HTTPS-only account.

  On the OP side, any account for https://x.y.z should trigger the complete block for any http://x.y.z ids.

  Thanks to John Bradley for some stimulating discussions on these issues.

tags: OpenID security transport security

[1] Mark mentions OAAM's strong authenication and risk based authentication technologies as potential solutions for OpenID's weaknesses. Maybe it is because I am not familir with this product, but I cannot see how OAAM can help with the weaknesses that occur through using HTTP (as opposed to HTTPS) for discovery. Likewise, socially engineered attacked can be effective in circumventing stronger authentication mechanisms (such as pictures or virtual keyboards) for less technology-sophisticated users: instead of their image, the rogue OP displays an error message along the lines of "Sorry, your personal image is currently unavailable due to maintenance. Please use standard authentication in the meantime." This might not work with all users, but I know enough folks who would login also with the "standard authentication" scheme.

This week's VRM Workshop at the Berkman Center in Cambridge, MA was quite interesting. It helped me quite a bit to sort out how Identity Management and VRM intersect, but also differ in some respect. To put it in a nutshell, I believe that the biggest difference between the two is that they are essentially two different ways of looking at the same problem. "Traditional" identity management has been focusing largely on the varies subjects (and objects), their characterization, and how they can be mapped to digital artifacts. VRM seems to be taking a more procedural approach by focusing more on the processes and interactions of these subjects, objects, and digital artifacts. In this sense, VRM and identity management are very much complimentary.

You can find more information about Doc Searls ideas about VRM on the Berkman wiki and on his blog.

vrm2008

OpenSocial and Liberty People Services are really tackling the same problem - only from two opposing sites. While the LAP PS has established a solid foundation for secure identity management, OpenSocial has started out to define an API for allowing social networking (but also other) software from different source to be run in one (or more than one) container. Ideally, these container abstract away the underlying platform and thus enable application portability. This becomes quite useful, since facebook, MySpace, Orkut, etc. have extremely similar types of applications (friends/relationships, photo sharing, contact management, and many more). Having these applications being portable across different allows application developers to focus more on added functionality and less on platform plumbing.

Liberty - on the other hand - has created the necessary infrastructure to enable individuals to set preferences and share information about themselves with other in a secure and privacy preserving way. The protocols used in ID-WSF and people service (and not APIs) can enable containers to communicate with others based on user's policies and requests.

libertyalliance opensocial

In my earlier article today I pointed out a rather significant security blunder in Germany, where a number of municipal IT departments failed to secure their systems. This lead  to exposure of at least 500,000 personal data records to the internet - so far I have not heard that any affected person was informed about their involuntary expose to identity thieves.

In this context it seems a little untimely to publicly announce a new electronic signature program that will start in 2012.Under this program, anyone claiming any benefits from any public source (unemployment, social security, etc.) will be required to use a smart card with a personal key. In addition, employer will have to submit all salary and compensation information to a federal, centralized database that will be fully accessible to all participating government agencies on the federal, state, and local level. Contained in this database are obviously all employer records, but - in all likelihood - also all data records of current or past applications for government benefits. Employees are expected to pay for these new services themselves, with private sector  financial institutions or government agencies playing the role of the trust broker.

This program is sold to the public in two ways: on the one hand, it is supposed to save the employers and the government agencies a lot of money by streamlining reporting and decision making processes. On the other hand, in its centralized form it is expected to help limit welfare fraud, which is quite common in Germany. 

In and by itself, such a database seems harmless enough: it has some tangebile benefits, including significant savings for the private and public sector. However, this effort does not stand by itself. Over the past couple of years, privacy from prying government eyes has been under the most severe attack immaginable: A comprehensive tax ID that is coma

While Germany and Europe in general have some of the strictest rules regarding the use and storage of personally identifiable information, the last few months have seen rather extreme data security breaches. Today, the German media is reporting about a new installment of irresponsible negligence government incompetence:

According to the SPIEGEL ONLINE a spokesperson for the software company HSH admitted that the personal information of more than 500,000 residents of at least 15 cities and towns were readily available on the internet for at least 3 months [1]. According to a investigative news program (Report aus München), this problem actually affected more than 200 municipalities for more than 3 years. The alleged cause for this blunder was rather simple: the software used by the cities to manage these huge data collections had at least one default/demo account that was not disabled by the IT staff of the authorities. These credentials were inadvertantly published by the software maker on their web site and thus available to every one.

While problems like this can happen, it seems odd that this massive security breach has not caused a major uproar with the various highly paid privacy guardians. In fact, there i svirtually no report on this incident in any language but German. One might get the impression that there is a strong desire with a rather large number of people to keep this incident on the q.t. and avoid further investitigations and public disclosures.

Germany has (or had?) after the horrible experiences with two dictatorships and their respective secret police a tradition of resistance against data collection and privacy invasion. The proposed general census of 1983 was stopped by the German Supreme Court in a decision that laid the foundation of what has recently been termed "Informationelles Selbstbestimmungsrecht" (right to informational self-determination).

So far, Germany has not seen a large number of identity theft cases: until last year, there was no unique ID  in use and most electronic transactions are currently handled through a European debit card system that is less exposed to a number of frauds. Also, while the various branches of government had been busy collecting large amounts of data on German citizens and residents, there have been only a few federal databases. When talking to people on the street, I found a growing indifference to the German governments extended data collection and linking programs. The general attitude seems to be that "we do not have anything to hide", and if a little (or even more than just a little) loss of privacy leads to a few high profile tax evasion prosecutions, everyone is happy.

[1] Germany has a national ID law that requires citizens to register with city hall and disclose persoanlly identifyable information such as names, current and former addresses, religious affiliation, birth date and place, children, current and former spouses, tax information, serial numbers of the national ID card and passport, and more. Since last year's July, this data also includes a tax ID, the German equivalent of a social security number.

While Germany and Europe in general have some of the strictest rules regarding the use and storage of personally identifiable information, the last few months have seen rather extreme data security breaches. Today, the German media is reporting about a new installment of irresponsible negligence government incompetence:

According to the SPIEGEL ONLINE a spokesperson for the software company HSH admitted that the personal information of more than 500,000 residents of at least 15 cities and towns were readily available on the internet for at least 3 months [1]. According to a investigative news program (Report aus München), this problem actually affected more than 200 municipalities for more than 3 years. The alleged cause for this blunder was rather simple: the software used by the cities to manage these huge data collections had at least one default/demo account that was not disabled by the IT staff of the authorities. These credentials were inadvertantly published by the software maker on their web site and thus available to every one.

While problems like this can happen, it seems odd that this massive security breach has not caused a major uproar with the various highly paid privacy guardians. In fact, there i svirtually no report on this incident in any language but German. One might get the impression that there is a strong desire with a rather large number of people to keep this incident on the q.t. and avoid further investitigations and public disclosures.

Germany has (or had?) after the horrible experiences with two dictatorships and their respective secret police a tradition of resistance against data collection and privacy invasion. The proposed general census of 1983 was stopped by the German Supreme Court in a decision that laid the foundation of what has recently been termed "Informationelles Selbstbestimmungsrecht" (right to informational self-determination).

So far, Germany has not seen a large number of identity theft cases: until last year, there was no unique ID  in use and most electronic transactions are currently handled through a European debit card system that is less exposed to a number of frauds. Also, while the various branches of government had been busy collecting large amounts of data on German citizens and residents, there have been only a few federal databases. When talking to people on the street, I found a growing indifference to the German governments extended data collection and linking programs. The general attitude seems to be that "we do not have anything to hide", and if a little (or even more than just a little) loss of privacy leads to a few high profile tax evasion prosecutions, everyone is happy.

[1] Germany has a national ID law that requires citizens to register with city hall and disclose persoanlly identifyable information such as names, current and former addresses, religious affiliation, birth date and place, children, current and former spouses, tax information, serial numbers of the national ID card and passport, and more. Since last year's July, this data also includes a tax ID, the German equivalent of a social security number.

Just back from Orlando, here are some takeaways from this year's TechEd 2008 for IT-pros:

• Interoperability with SOAP based web services is progressing: I was part of a panel on interoperability, moderated by Chris Haddad. It was a fairly diverse panel, with speakers from Microsoft, WSO2, Tibco, and Sun. While there was general agreement on the usefulness of the more basic WS-* specifications like WS-Security, opinions differed on where the future lies and how it can be achieved. In my opinion, the relatively high fidelity of interoperability within the WS-SX family of specifications is a direct result of the proper standardization process at OASIS that these specs were subjected to, comparable to that of ebXML or SAML 2.0. Thus, it is my expectation that the WS-RX and WS-TX protocol families will eventually yield similarly good interoperability.
• For the "Demo that almost made it (TM)", we made some serious progress: After talking to Greg Leake of Microsoft and Jonathan Marsh of WSO2, I am quite optimistinc that we can get easily inject a Metro based STS and/or OpenSSO with WS-Trust and CardSpace support into the StockTrader sample application to allow authentication through a SAML token. At the same time, I think that this demo application in particular lends itself quite nicely to showcase the strength of the Liberty framework for web services: you have a web application that needs to interact with the Business Services and the Order Processing Service. Identity has to be preserved across these different tiers, yet privacy protection would be highly desirable.
  
• It was very interesting to see that Microsoft is continuing on the path of interoperability in the systems management area. Three years after we demonstrated MOM 2005 managing and monitoring a Sun v40z with Solaris, Microsofts System Center beta features an open source Solaris management adapter. An interesting question is where this code will be hosted ...

It took quite a while, but by now it is out. Please welcome the Windows CardSpace Information Card extensions for OpenSSO:

https://opensso.dev.java.net/source/browse/opensso/extensions/authnicip/

When I started working on this last spring, I was not even hoping to see this released in open source and part of the OpenSSO extensions family in less than a year. It took the goodwill and talent of quite a few people to get this off the ground, but with the public release of this code and the upcoming OSIS interop during the RSA onference, OpenSSO is now "speaking ISIP" ...

tag: CardSpace, OpenSSO, InfoCards

Pat, Ben, and Kim have been talking about the use of password tokens for use with Windows CardSpace. Pat's detailed description of how this could work is quite useful, and can be extended in some interesting ways:

1. Create a single-use password deployment

If we change the default WS-Sec username/password token to not only include the username and the password needed to login, but also a newly IdP generated second password that replaces the old one on the RP, we would get a single-use password. This might be quite useful for improving the security of the system.

For the rest of this article, I will call such a token "Extended Username/Password token" (EUPT).

2. Creating an account at the RP

One of the issues that Kim has an issue with is that for bootstraping into a CardSpace password manager setup, the user would be required to enter the initial password into a web form. I agree that this *is* bad, but an extended username/password token could help here, too:
When the user does not yet have an account at the RP, he will need to login at a special URL. That URL accepts cards that support EUPTs. When the user creates the account, the RP will accept an EUPT with *any* values. These initial values (username AND password) are randomly generated at the IdP. Upon receipt of the EUPT, the RP stores the username and the initial password and associates it with the newly created account.

--

Time permitting, I will work with Pat to get this done, at least on the IdP side.

tag: Identity, CardSpace, OpenSSO

Eve was kind enough to link to my earlier article on our CardSpace Deep Dive. In that post she mentions our whiteboard notes, that I took at picture of, after all:

Cards based on X.509 authentication are almost working ... there is still a small issue with identifying the right certs based on the thumbprint. Overall, a fairly good result, I'd say

tag: Interoperability, Identity, CardSpace

Hubert and Marc have been working on a very interesting subject: using RESTful service for identity. Please take a quick look at Hubert's blog - he is working on a series of articles on this subject.

tag: Identity, REST

Not about SCUBA this time: we are right now visting in Redmond so we can test our implementation of a Windows CardSpace compatible IdP against Microsoft's implementation. Eventually, we will (hopefully) make this code available to the OpenSSO community through an OpenSSO Extension.

At the core of the integration, we (Paul, Jiandong,Mrudul, and I) have integrated the Metro/WSIT WS-Trust STS into OpenFM and created a simple cardfactory to produce CRD files (a big thank you to Chuck from here for letting us use some of his Openinfocard code). While we are not quite done as of yet, we have made some very significant progress towards full interoperability while supporting the username/password token, as well as X.509 client authentication.

Overall, this project has already helped quite a bit to improve interoperability between the underlying technologies (i.e. WSIT and the subset of WCF that is being used by CardSpace) and I expect that we will be pretty much done with the core code base in the RSA 2008 time frame.

Many thanks from here go to Mike Jones, Nigel Watling and the entire Microsoft CardSpace team.

tag: CardSpace, OpenSSO, Interoperability, Identity

Another one done. IIW 2007b is over, and - overall - it was quite productive for me.

The biggest takeaway for me is that Concordia and OSIS have made - in my mind - a major step towards harmonization and better coordination. This was reflected in the results of the OSIS steering committee meeting on Wednesday and the following two sessions on Concordia. I am glad that all participants recognized the value of both organizations. As Mike Jones put it, it helps that there is significant overlap in the members.

Other progress was made as well by both groups - the OSIS interop planning session was very fruitful, especially since the planning committee prepared an excellent laundry list document consolidating all test that are in the planning for RSA. I heard great things about the Monday Concordia meeting (which I was unfortunately unable to attend), but also the Use Case session on Wednesday with Paul and Mike was extremely productive.

Finally, the OpenID folks are to be mentioned for making a breakthrough with their 2.0 release, including their IPR regime. I took the Liberty (sic!) to capture the moment that David et al. have been waiting for more than a year:

Overall, the atmosphere seemed a lot mellower, but I can not really follow Dave's conclusions - especially concerning his comments about Concordia and OSIS.

tag: iiw2007b, osis, project concordia

Mike made a very good remark on the OSIS General mailing list that seems relevant to the discussion between Pam, Paul, and myself about assurance in distributed security:

There's a reason that self-issued cards didn't provide any ability to transmit a credit card number or national ID number. The good news is that Identity Providers sending such sensitive information are likely to not be willing to transmit it to relying parties they don't have a business relationship with. Once you're using managed cards for payment rather than typing credit card numbers into web forms, you'll definitely have additional layers of protection working for you. [...]

I fully agree with Mike here: as fas as I understand, Mike is describing the IdP deployment model that Paul and I have been championing over the use of self-asserted cards for sensitive attributes.

tag: assurance, identity, cardspace

Paul found an "periodic" table of data visualizations, which is quite nice in its own right (Paul: I think I have seen a knowledge map of the identity landscape some time ago). But I certainly prefer this "periodic" table of ... beers (hmmm).

tag: humor, beer

... that I will not let anybody break my windows - also, they seem to be a little stronger than the Jones' windows, at least the big one in the spotlight.

In the latest round, Pamela explains how a particular authentication should be considered to have a particular level of assurance. Paul takes the time to address some of the issues Pamela raises, but before we loose track of where we started, I would like to point back to the initial discussion between Pam and Paul:

Paul wrote:

In discussing Cardspace's relaxation of the SSL requirement for RPs, Pam writes

We now theoretically will have three different assurance levels going, based on three different ssl certificate levels (no certs, regular certs, and HA certs).

For there to be 3 Cardspace assurance levels would imply that the LoA is the same for self-asserted and managed cards. Is this the case?

Pam originally thought about three levels of assurance that were bound to the level of the certificates: none, regular, EV^[1]. Paul noted that the level of assurance depends on a number of factors, with technology and deployment architecture only having a small part in this. Paul and I then tried to elaborate in more detail how technical and non-technical factors affect the assurance an user and a RP can place into the transaction.

The reason I started this discussion was that - in my mind - the security certificate used in a particular authentication or authorization transaction is essentially only one reputation factor: by wielding an SSL or EV certificate you demonstrate that a particular company (the CA) thinks that you are who you say you are. This certainly affects assurance, but - by itself - it is rather useless.

The identity provider model (which derives from the mutual trust model in Kerberos) adds a very significant layer to the assurance model: It goes beyond the generic assurance by e.g. a CA by offering information (authentication, attributes) about a particular group of users - the IdP is by far more specific than the CA. Additionally - as Paul points out - a trustworthy IdP is typically a company with deep pockets - someone a RPor an user can sue for damages if something goes wrong. Note that the Windows CardSpace system support such an IdP deployment by using managed cards with Issuer policy. I expect this to be the default deployment for CardSpace, if it gets selected by large organizations.

Self-issued cards or managed cards from any IdP (the OpenID model) do not offer the comfort of sueable deep pockets to the RP. A RP that trusts an authentication that is done by anyone but himself will find himself in a rather dangerous situation: if something goes terribly wrong (e.g. some nasty mal-ware rootkit stole my self-asserted cards along with usage logs and sent them to a criminal for use with my bank) the burden is then on the RP to prove that the authentication token it received did not originate at my Windows CardSpace client, but at the criminal's computer. In an IdP model this burden is with the IdP^[2].

Thus with all respect to Pam's critique, I do have to insist on my original point: the technical factors (like an EV cert or lack thereof) play some role in the level of assurance, but only to establish a baseline. What allows RPs and their customers to truly trust in an identity system are the deployment parameters (including such "mundane" but at least equally important things as e.g. physical security), and - most importantly - the established mechanisms of society for enforcement, arbitration, and liability management.

tag: assurance, cardspace, identity

[1] By the way: the recognition that different types of security certificates might even on influence the assurance you have about a transaction invalidates Ben Laurie's argument that third parties do not add additional assurance.

[2] If I were a cynic, I'd might come up with this argument: Since there is likely a contract between a RP and an IdP, and the IdP has all kinds of lawyers working for them and an interest in precting itself and its users (to a degree), the RP would actually be much better off with self-issued cards: if something breaks, the RP can

• blame the end-user about their lack of security precaution and sue them for negligence,
  
• rest assured that no large number of lawyers will counter-sue them,
• offer the end-user a token of reparations ("We will cover 50% of your losses") and earn tons of goodwill for marketing purposes.
  

Fortunately, I am not a cynic.

Paul Trevithick just announced that Higgins will start developing a SAML 2.0 compliant card selector, that will - in addition to Windows CardSpace compatible i-cards - support SAML 2.0 compatible "s-cards"^[1]. This will be quite interesting to follow, in particular if Higgins really supports the SAML 2.0 protocol (not only the token format). In that case it would really step up to be part of the identity meta system (actually: the Aleph 0 Identity System ).

PS: Welcome in the blogosphere, Paul!

tag: saml, identity, higgins, liberty

[1] Paul Madsen made some interesting remarks about that name...

Paul and Pam seem to think that my stance on assurances and trust is hard-line.

No Assurance vs. Pseudonymity

Paul seems to agree with me to some extend while noting that a concept like self-issued cards can establish a stable pseudonym. I agree with this: both the Windows CardSpace system, as well as OpenID produce in their basic usage scenarios^[1] stable pseudonyms - not more, not less. But this conveys nothing about the identity of the user controlling this pseudonym. It is purely an authentication process that takes place, with no authorization data being exchanged. In fact, all authorization takes place within the RP system, solely based on the pseudonym. I called that the "No assurance" level, which is - a little - harsh, but still fair.

Pseudonymity and Low-Value Transactions

Pam has more issues with my analysis: initially, she finds it strange that "No assurance", pseudonym-only level of assurance is acceptable at all. Again, I might have been somewhat extreme in my wording: when speaking about "No assurance" I was speaking about a situation, where some authentication, but no authorization took place. So you do have (as Paul pointed out) a stable pseudonym, but absolutely no reliable information beyond that. This, I find completely acceptable to what I coined "low-value transactions" like forums, blog commenting, etc.

Trusting an IdP

Now Pam goes on to point out, that an arbitrary managed card provider has - beyond the certificate that confirms the identity of the IdP to only some extend  - no other trustworthiness to them, making them practically as unreliable as a self-issued card.

I agree totally. That is why I insisted in my earlier article that in order to gain any confidence in the token, the RP has really no other choice but to set the sp:IssuedToken/sp:Issuer (3.1.1 [ISIP 07]) to a WSA Endpoint that the RP is willing to trust. This trust is established through non-technical means, e.g through contracts, reputation systems, etc. But without this tying of the authentication to an IdP you have at least some trust in, you cannot have any reasonable level of assurance about your attributes.

The Energy Level Diagram of Assurance

Thus, I also agree with Kim: assurance is not binary - quite the opposite. For reasons of brevity (and laziness 8-)) I only focused on the two major categories of assurance for authenticated session. So here is now a somewhat more complete picture:

Please note that in this picture "No assurance" refers to completely anonymous transactions (no authentication), while the former level of that name is now name "Pseudonymity".

At the end of the day, however, I come back to the same point I made in my earlier post: technology (as long as it is not blatantly broken, i.e. insecure) bears no significant role in establishing trust or assurance. You cannot create a technology that has "built-in" trust - any technology can be deployed in a completely untrustworthy way.

Even a technology-centric system like SSL rests on the trustworthiness of the browser programmers (that put roots in the CA stores) and the CA companies themselves.

tag: identity, assurance, cardspace

[1] Windows CardSpace: self-asserted cards, OpenID: OpenID Auth 1.1 + SimpleReg 1.0

[ISIP 07]   Arun Nanda, "Identity Selector Interoperability Profile V1.0", Microsoft, April 2007

Well, this is over ... and on to the next.

The last week was quite busy since Mrudul Uchil (from the OpenSSO team), Jiandong Guo (from Metro) and I were scrambling to teach OpenSSO to issue InfoCards for Windows CardSpace and respond correctly to WS-Trust STRs. Overall, it went quite ok and this excercise uncovered a few issues that will help us make the product better. The idea is to make this code accessible to the general public as soon as we can - but please bear in mind that we had to make changes to WSIT/Metro and OpenSSO, and some of these are not (yet) considered critical for the products. Nevertheless, I will be working towards a release for the IIW 2007b timeframe, so that we can progress.

Eve posted a couple of thoughts and some nice pictures of the interop session ... go check it out.

tag: identity, interoperability, InfoCard, opensso

This comes through Lauren. I can only fully agree with her recommendation of watching and sharing this clip with anybody that has kids or is concerned about the security of our children.

This is very creepy and shows the high level of immorality of the toy industry. With aggressive data hoarders like this, it seems more urgent than ever to even go beyond an opt-in regime (which we do not - yet - have in the U.S.) and put heavy financial liability burdens on any company holding or handling information about children under 17. Also, I think that consent mechanisms for children must be changed in a way that makes it impossible for children and parents to consent to privacy regimes that can be detrimental to children.

What makes this even more scary is that local governments are obviously not fully aware of the privacy ramifications of these organized privacy violators. For example, the Town of Burlington, MA, offers through its recreation department a class (see here, p. 5) for parents and children to make special "things" for their WebKinz.

tag: identity, privacy, policy, children, ID Theft

Tim Bass responds to my objections to his earlier article on the immaturity of modern identity protocols. He makes the valid point that the maturity of a technology should not be measured by the time it has been available, but by the level of adoption and actual deployment numbers:

"On other other hand, I am measuring “maturity” by actual usage, and the proof of security solutions is in the actual adoption, not simply years of standards activity and vendor marketing." (Tim Bass)

I fully agree with Tim that this is a very important factor in evaluating the maturity of a given technology, probably more important than the technologies availability. In fact, my earlier post was not very clear on this. On the other hand, I do believe that an extended peer review with subsequent revisions does contribute to the maturing of a given technology.

It turns out that SAML and its related technologies (Shibboleth and Liberty) excel in both these requirements for maturity:

1. As I pointed out earlier, SAML (the concepts as well as the technology) has been peer reviewed since 2001 by a number of very different organizations such as OASIS, Liberty Alliance, and Internet 2. This extensive review process resulted in two subsequent versions, that incorporated security fixes and enhancements, as well as new features. It has very broad community and industry support from open source projects, universities, and companies like Microsoft, Oracle, Novell, HP, Sun and many, many others. For more information take a look e.g. at Eve's blog or Scott's presentation.
   
2. SAML has been deployed on a very broad scale. There are a number of not-so-visible financial and telco deployment that are huge, but also the highly visible higher education deployments (see here). In fact, there are few (if any) other web centric identity related technologies that can boast an adoption comparable to SAML.
   

So, at the end of the day, I still maintain that Tim's assessment of SAML as an immature technology is - at least - incomplete.

tag: saml, identity, protocols, cybersecurity, standards

Paul picks up on an article by Pam about level of assurance with Windows CardSpace. He emphasizes the important point that assurance is not only affected by the underlying technology, but also by non-technical parameters like contracts.

I would go one step further and say that LoA is almost exclusively affected by non-technical factors. To be able to put any trust into a given authentication system (let alone an authorization system) you need minimally:

1. A contract between the RP and the IdP
2. A contract between the user and the IdP

Both contracts need to have provisions for the following areas:

1. Data governance (including privacy assurances and data handling)
2. Fault handling
3. Data updates
4. Contract termination
   
5. Liability
   
6. Arbitration and conflict resolution
   

Without such a framework most authentication and all authorization systems are only useful for 'low-value transactions' such as blogging or simple social networking. Or - in other terms - there is no level of assurance, even if the underlying technology supports the most fancy certificates or crypto algorithms.

Obviously, contracts of such kind can only be meaningful and economically viable, if the underlying technology is not broken and has the necessary features to support such provisions^[1].

Now, as far as the Windows CardSpace identity system is concerned, there are indeed multiple levels of assurance for the RP:

1. No assurance - self-managed cards, or any managed card where the Issuer is not enforced by the RP
2. Assurance - managed cards where a particular set of Issuer(s) is required by the R

Only in the later case there can be a reasonable level of trust by the RP that the user is actually who he/she claims to be relative to a given IdP. In that case the contract provisions between the RP and the IdP are in effect and it will depend on them how much trust the RP can put into the authentication and attribute statements.

The Liberty identity system has the necessarily technology and the business and legal frameworks for providing a very high level of assurance, but they are currently not ideally equipped to address the needs of little or no assurance (which typically include fast and extremely easy deployments). Hopefully, openLiberty wil help address these issues.

tag: identity, WCS, Liberty

[1]Thus, any identity system that relies on an universal federation (i.e. any IdP is admissible) cannot provide any meaningful level of assurance.

It seems that history is about to repeat itself: after Liberty formed, a lot of people wither felt left out or did not understand what all this 'identity stuff' was good for. Granted, Liberty was in 2002 about 5 years ahead of the rest of the market. At the time, I thought that this perception problem could be attributed to some abysmally bad marketing - I guess that this was only partially correct.

Today, the same complete lack of understanding is about to hit the "user-centric" identity community as well: Take a look at a post by Brian Huff and compare that with this post from Tim Bass (via James McGovern).

It seems astounding to me that both authors (who claim to be working in 'SOA') have so little understanding of the problems, technologies, and solutions in the identity space. Granted, I am a geek working in this area, but both Tim and Bex claim to be architects and decorate themselves with shiny titles (CTO, CISSP, Oracle ACE Director). They should know better.

Both advocate (in so many words) 'a simpler identity system' (heard that one before) and 'authentication - and that's it'. Both paint existing standards in a very bad light, describing them as 'immature, confusing and less-than-proven  security standards' or asking 'Makes you wonder why people bother to call them "standard," doesn't it?'.

Ok, guys you do not understand identity - get over it and hire someone who does. The good old days where everyone was getting ready for the global directory and its PKI are over. It's not only about authN and authZ in these days, but about the much bigger business and regulatory issue like trust or identity theft.

It seems that the larger identity community (Liberty, InfoCard, OpenID) is about to experience the same pushback that Liberty was facing initially. Let us hope that our joint communication efforts today will help to get over this 'perception gap'.

--

Here are a few comments regarding Brian's post:

1. CardSpace, OpenID, SXIP, (parts of) WS-*
Are not even by the widest possible definition standards, but rather a collection of protocol specifications. Some of these are even proprietary, IPR protected technologies (e.g. SXIP) that are not even covered by a NAC. Also, why are you not including real identity protocols by industry consortia, that are free to implement like e.g. ID-WSF?

2. SPML, XDAS
These OASIS standards have - per se - nothing to do with identity. They *touch* upon identity and security, but are not core to it. Otherwise you should also include HTTP, IMAP, SOAP, and even TCP.

3. LDAP, SAML 2, (parts of) WS-*, XACML
The are (in a wider sense) identity and security related standards. But so are many, many others (Kerberos, X.509, WSPL, XML-Enc, etc.) that you chose to omit. And interestingly enough, most of these standards build on each other or are complementary. So where is the issue?

4. The API issue
There is no unified, standadized API to all these protocols? For starters, only protocol organizations typically create protocols, not APIs (one notable exception is the GSS-API). If you want to create a 'standard' identity API, go to the JCP and suggest a JSR. That organization is probably the body with the biggest amount of standardized APIs, and it is - by most standards - fairly open today. On the other side, if you take the contract-first approach serious, every WSDL or SOAP profile is a reasonable API documentation. In fact this approach allows you select your platform of choice.

Regarding Tim's post:

His list of immature protocols is simply ridiculous: SAML - well established since 2001: go ask the Shib folks, who are running the larger chunk of the academic environment on this protocol. XML Enc and Dsig - yes, there are a few problems (authenticated encryption or key exchange), but none of these problems are insurmountable and have been solved for a long time.

tag: identity, saml

Kim writes about the recent Beta announcement^[1] at Windows Live! about them accepting Windows CardSpace InfoCards for authentication. Having gone through rolling out an extensive public new and experimental Identity System deployment myself (Lauren is currently writing about that), I can appreciate the work that Kim and his colleagues are putting in.

In the interest of distilling use cases for Project Concordia and other venues it seems worth pointing out that - in this deployment - Windows CardSpace is being used solely as an authentication system: You can associate any Windows CardSpace card (only PPID is required) with your account - all other attributes are still being handled by the backend systems of Windows Live!. Any additional attributes that your Windows CardSpace card can provide will not be used for authentication or authorization.

This is very much in line with my description of the "glorified HTTP Redirect" use case of Windows CardSpace: here the secure UI on the client can actually help in preventing phishing attacks. The biggest competitor for this use case is OpenID which offers (roughly) the same features, but employs a radically different approach at solving the authentication problem. With PAPE it is somewhat more phishing resistant, but at this point, the CardSpace-based identity systems have - from my perspective - a clear lead in this area over OpenID.

Both authentication technologies face however that same issues: they allow delegation of responsibility for authentication and a rudimentary attribute exchange mechanism. But they do not address the need of service providers to maintain ownership of attributes about their users, except in trivial cases. For these - business driven - issues you need a framework that allows advanced models of federation and account linking and  - most importantly - goes beyond protocols and addresses the non-technical aspects of identity management as well.

I think it will be quite interesting which authentication technology (OpenID and Windows CardSpace) will get how much market space. OpenID has a head start as far as IdPs and community acceptance goes, but Windows CardSpace has the backing of Microsoft and - starting with Windows Server 2008 - a REALLY large number of relying parties.

tag: identity, OpenID, WCS, interoperability

[1] The service has been available for some time now.

Yesterday, Kim Cameron picked up on a recent article Bob Blakley. The central theme is about Stefan Brands' criticism of OpenID. While Bob sets out to ask the OpenID 2.0 folks some hard questions about what kind of problem they are actually trying to solve, Kim opines that some of the criticism brought forward by Stefan (and Bob) is unfair, since it is out of the scope of what the original intent for OpenID was.

Instead, Kim suggests that there is a spectrum of identity systems which address different needs. Thus, all such systems including SAML 2, WS-Federation and - by extension - the WS-Trust based InfoCard identity system^[1] should answer the questions posed by Bob to OpenID 2.0:

"[Bob] argues that the OpenID specification should include an articulation of the constraints on what it is attempting to achieve.

I agree, with the proviso that other protocols, like SAML 2.0 and WS-Federation, should do the same."

A lofty goal, who could not agree to that: it is most crucial that software architects and designers spend time on defining the boundaries of a given solution. However, prior to limiting and classifying solutions, it would also be neat to actually identify (sic!) the problem/use-case of the solution under examination.

Although I try not to sound like a broken record, I do have to come back to a favorite theme song of mine: Liberty Alliance has done all these nasty and boring use-case evaluations, requirements, and scope definition like privacy and trust evaluations. Interestingly enough, a lot of these often fairly generic assessments is indirectly offered to other identity systems through Project Concordia.

tag: identity, OpenID, Liberty Alliance, meta-system, InfoCard

[1] Kim writes: "Popping up a level, we need a spectrum of solutions to identity problems.  Ergo, the identity metasystem." This is - in my opinion - an obvious example of why the term identity meta-system is very misleading: here it does not necessarily refer to the 'meta'-system defined by the InfoCard architecture, but rather to what I jokingly referred to as the "Aleph 0 Identity System" - a 'true' meta-system of protocols, deployments, etc.
But such a 'true' meta-system is not exclusively a WS-Trust based replacement for HTTP Redirect (WSTBRFHR), like the InfoCard identity system .

There has been quite a bit of discussion about SXIP's recent OpenID Infocard token profile: Johnny Bufu, Peter Williams, and I had some email exchanges, Eve commented on Eric's blog, and Dick made some comments about his view on the IPR status.

All this is great, exciting, or anything else you might want to use for describing conditions of euphoria. And I do acknowledge the work that Dick, Johnny, and Mike put into this effort. However, the big questions that are still unanswered (at least for me) is: who cares? And: are we hurting ourselves?

The Bigger Picture

If I take a look at the deployment rate of new-identity-protocol relying parties, i.e. mostly OpenID and Infocard, the picture is rather sobering: there is little activity^[1] and currently also few signs that this might change. One of the interesting results of the recent OpenID project at Sun was that successful web property owners have little or no interest in outsourcing their identity system, or even only the authentication part of it (which is the only established role of OpenID or Infocards at this time).

The same kind of behavior can also be seen on a larger scale where the big application and service providers like Google, Facebook, or Yahoo! have little or no real interest in a truly federated/distributed internet-wide identity system, since it is not compatible with their respective business models^[2].

So overall, it seems safe to assume that any effort directed at convincing web property owners to adopt a particular identity system is an uphill battle. Especially, if they have to invest time and money into equipping their web server with a compatible relying party.

OpenID Tokens, Anyone?

Now, what would be required to use the OpenID Infocard token profile? In addition to the entire OpenID infrastructure (OpenID Auth 2.0 et al.), you would also need a - more or less - complete Infocard infrastructure. In addition, you would need to make sure that the respective parts are tightly synchronized ^[3].

In addition, none of the OpenID specifications have passed extensive peer review in an open standards process, have IPR issues plastered all over them, and are - pretty much - all in beta (or pre-alpha) at this time.While these issues have been discussed in the past, it still seems reasonable to point out in this context.

Rolling out a complete and fully supported Infocard infrastructure is somewhat easier, since Microsoft is providing de facto reference implementations for the card selector and the relying party. Also, the IPR situation is less confusing, since the OSP covers - as far as I can see at this time - a pretty large chunk of the complete Infocard identity system.

Who cares now?

For a potential deployer, the question is now: "If I have an (almost) shrink-wrap identity called Windows CardSpace, why should I start to dabble with the deployment and replace the built-in SAML tokens with OpenID tokens?" Besides the technical difficulties, there is also the issue that an OpenID token based Infocard deployment only allow what is called "auditing mode". Add to that, that most clients will probaby not have Infocards with the OpenID tokens installed, my initial questions come up again: who cares? And: are we hurting ourselves?

Most end-users do not care at all. In an Infocard-world, they just want to use the Windows CardSpace selector to login. If a given site does not support self-signed cards or a managed card they already have, chances are that they will simply go away.

The relying parties do not care either: most of them want to attract users to their sites. If there is a simple SSO/identity system they can deploy and buy support for, they probably will as long as it fits their business model. Many successful Liberty deployments attest to that. If it involves unreleased or unsupportable technology, potential patent disputes, or simply a lot of additional work, they will likely shy away from such a solution.

There are also no benefits to the IdPs: having to run a combined OpenID/Infocard infrastructure might attribute only to a little administrative overhead, but it does not really add a lot of additional benefits either.

Are We Hurting Ourselves?

My answer to this would be a decisive: "yes". While the OpenID Infocard token replaces the HTTP redirect with the much more phishing resistant Infocard scheme, it will lead to some significant confusion in the marketplace. Educating customers and end-users might help to some extent, but explaining the differences between auditing and non-auditing mode is going to be very difficult. This is why Kim is rather careful about not advocating it: it breaks his own 7 laws.

At the end of the day, relying parties will have to decide what they want to do - and it seems to me that the decision for or against a particular identity system (such as Liberty, Infocard, or OpenID) will not be based on tokens, but rather on the entire package, including vendor support, reachable customers, and overall acceptance.

tag: identity, OpenID, Liberty Alliance, SSO, InfoCard

[1] Especially when comparing this with the rate of IdP rollouts for these protocols.

[2] In fact, I would argue that the interoperability debates of the 90s - WindowsNT/Active Directory, eDirectory, LDAP, etc. - were focused on the same issue of identity. At that time, it was the software suppliers fighting over identity WITHIN the enterprise, since control over the user database was the key to influence a lot of strategic decisions.

[3] To be fair, this is true for all complex interoperability scenarios.

Just some Friday humor:

tag: facebook, identity, humor

Just a quick update: OpenSSO is now using the WSIT/Metro STS for WS-Trust protocol transactions. Congratulations to the team (and especially Mrudul) for getting this done!

tag: identity, opensource, opensso, ws-trust

During last week's Project Concordia call, we had an interesting discussion about cross-protocol identity use cases and scenarios. Ashish made a very good observation during this call: many times when we are discussing identity protocol transitions or cross-protocol use cases, we are not so much dealing with protocol interoperability, but rather with a protocol mashup.

Proper interoperability - in this definition - requires the ability to interpret foreign protocols and have full access to the semantical content. I have sometime referred to this level of interoperability as interchangeability. An example of such high level of interoperability would be the ability to extract authorization data from a Microsoft Kerberos ticket and use the NT-PAC data to create a SAML attribute statement.

A protocol mashup on the other hand would only require very limited knowledge about the semantics of another protocol, but instead it simply profiles the use of one protocol (or in this case: identity system) with another. A simple example would be the use of self-signed InfoCards to authenticate to an OpenID Provider.

tag: interoperability, identity, Liberty Alliance, OpenID, InfoCard

Tatsuo Kudo wrote an article in Japanese on how to configure the OpenID Extension for OpenSSO. As far as I could see (http://tinyurl.com/35gfuh), this is a great article.

tag: openid, sunopenid, opensso

With this article I will try to clean up a little bit of the confusion that I help to create over the past few days. You might want to ask "WHY?" The answer to this is quite obvious: the medium is the message: the content of a message and how it is received depends strongly on the form it is presented in.

This will be my last post on the subject of "meta"-ness. At least for the time being.

It seems to me that there is a fundamental disconnect about what a system differentiates from a meta-system. For myself^[1] (and it seems also for Paul and Robin), a system is a set of rules, protocols, profiles, etc. that are to be implemented. For example, there is a system in place that governs the quality of gasoline and automobile motors, and its standard ways of distribution. This system consists of rules, regulations, engineering practices etc.

From what I gathered in the recent discussion with Bob and Pamela, it seems that they would call these rule-sets a meta-system (please correct me, if I am wrong). If I understand them correctly, the individual gasstations, car manufacturers, refineries, etc. would be called systems.

So far this comparative example held up well, therefore I will be trying to overstrech it now: To me, a meta-system would govern how e.g. different car fuel systems (such as hydrogen, electricity, natural gas) could be made to work together. Examples of this would be creating user devices cars or identity/service providers gas stations that can consume or dispense different types of fuels.

I am not quite sure what the right term for this would be, but the dreaded meta-meta-system certainly comes to mind. That is why I suggested (only half-jokingly) the term aleph 0 system^[2]since it would equalize the different 'starting points'.

---

Now, applying these thoughts to the identity world, I come to the following conclusions:

• Of the three contenders (Liberty, CardSpace, OpenID) for identity systems Liberty was the first identity meta-system.
  
• Concordia will hopefully serve us to arrive at an identity meta-system (better: an aleph 0 identity system).
  
• OSIS has so far tested implementations of identity systems (i.e. identity meta-systems), and will hopefully expand to use cases for identity meta-systems.
  

tag: identity, meta-system, meta-meta system

[1] In this article I will mark the terms system and meta-system either in blue or in orange, depending on whether I use them in my way or with the meaning that Bob and Pam have in mind.

[2] Ok, anybody with a better term?

There seems to be a little confusion over the differences between identity systems and meta identity systems. Some identirati are of the opinion that in order to qualify for the "meta" tag it suffices to support a single family of protocols and multiple token formats, while others are convinced that a "meta" system should also support multiple protocols.

Since this seems confusing to me, I implicitly suggested to call the later an "identity meta-meta-system". Opening this can of worms, you can easily derive at an "identity meta-meta-meta-system" etc. to include other staggering advances in interoperability such as semantics.

To prevent this kind of meta proliferation, I am now convinced that we should define the goal of "getting-these-pesky-identity-thingies-to-work-with-each-other": Aleph₀ Identity System (AIS) [1]. The AIS can - by definition - not be implemented, but describes the elysian state, where all identity systems that would like to be interoperable or interchangeable, are interoperable or interchangeable with all others participating in the Aleph₀ Identity System.

tag: identity, meta-system, meta-meta system, humor

[1] This is motivated by the notion that the cardinality of a countable set (in this case the meta's) is commonly denoted by Aleph 0:

Both Paul and Robin beat me to this ...

The recently published report by Burton's Bob Blakley summarizes the result of an interoperability testing fest at the Burton Catalyst conference earlier this year. This venue was a great success for the Windows CardSpace identity system, since it was the second OSIS event where a variety of open source projects and closed source commercial products demonstrated a significant level of interoperability. Given the early and evolving state of the InfoCard system, this is a great success for all parties involved.

However, Bob is somewhat mistaken in parts of his article:

"The interop participants accomplished in two months of concentrated effort what it would probably have taken them a year to do working independently without the looming deadline provided by the Catalyst demo."

This is not quite correct - the Catalyst interop fest was the second such event organized by OSIS. The first one was held earlier at the Internet Identity Workshop 2007. Results and blog reports on this can be found all over. Having been a member of OSIS for some time now, I find it a little unfair that this interesting (un)organization - that certainly had its ups and downs - is not given the credit it deserves.

"While it is still fair to say that user-centric identity technology is in its infancy, if progress continues at this rate the technology should be ready for enterprise adoption within a year."

I am surprised to see such a bold statement, especially since even some of the core developers and architects not quite happy with the term "user-centric identity". Let's just step back and start to count how many glossaries, lexicons, and lists-of-used-terms define digital identity, identity system, user, and user-centric in different ways with sometimes completely different semantics. Predicting enterprise adoption within a year seems a little overly optimistic to me, especially if we consider that there are still a number of significant issues even within the reference implementation of the InfoCard identity system.

As Mark Wahl has pointed out earlier, most of the issues encountered during the second OSIS interoperability fest are related to the lack of proper schema management for attributes and their semantics [1]. The only project in the Infocard system currently working on these issues is Higgins, with their use of OWL (although some people might argue that this is technological overkill).

Outside of the InfoCard system, there have been other efforts to get to at least some standardization of attribute interpretation (SAML attribute profiles, which work nicely with LDAP/X.500 and XACML and other likely sources) and work is being taken up by Liberty to standardize identity attribute sharing rules (e.g. the IGF/IDG work, based on CARML/AAPML).

At the end of the day (closing the loop and coming back to Paul's and Robin's point): Even though there have been a number of different products and projects that successfully worked together, this technology is a far cry from being an identity meta-system. Multiple-protocol interop on the wire would be a true metasystem, and is a goal that various systems -- Liberty, OpenID, and Windows CardSpace included -- would need to work on together. Concordia is (probably more than) a first step towards this goal.

tag: identity, IIW2007, interoperability, InfoCard, WCS
 
[1] Obviously a lesson well learned through the LDAP and - even worse - LDUP discussions.

Here is a thought on privacy in Germany: it often appears that privacy protection is taken very seriously in Germany and citizens have decent control over who gets access to their personally identifiable information. I was under that impression myself for a long time, until a discussion with a friend prompted me to take a closer look at the situation.

I was extremely surprised to see how little privacy protection actually exists in Germany - with respect to the government. It is true that the federal data protection act ("Bundesdatenschutzgesetz") puts a lid on obtaining, storing, evaluating, and disseminating personal data, especially for the private sector. In general, the "opt-in" principle is followed, where the data subject must give express permission to collect or store PII, and has the right to recall such permission at any time. However, this federal law also makes it clear that some or all of these provisions can be lifted by specialized laws.

One set of these laws limiting the federal data protection act are the laws requiring every person living in Germany to register with city hall when taking residence ("Meldegesetze"). These laws actually precede the data protection laws and allow the registration agency ("Einwohnermeldeamt") to collect and store the following attributes:

1. all names (including former names, pseudonyms, etc.) and academic titles

2. DOB, place of birth, sex

3. addresses (all current and former), including the dates when they changed

4. legal guardian(s), including addresses, DOB, date of death, titles, etc.

5. all citizenships

6. religious affiliation

7. marital status, including dates and reasons for changes

8. spouse (including names, titles, DOB, date of death, all current and former addresses)

9. underage children (again, names, titles, DOB, ... you get the idea)

10. date and place of death

11. restrictions for releasing this data

12. eligibility to vote in national or European elections

13. tax relevant data (including religious affiliation of spouse)

14. unique tax ID (as soon as its issued)

15. weapon permits, demolition permits

All this data is - more or less - freely accessible to any government agency, including the German internal revenue department and federal tax agencies, welfare offices, motor vehicle registries and licensed religious institutions.

In addition, the registration agencies will release your core data (names, titles, addresses) to any thrid party that asks without notifying you. If said third party has a reasonable interest (e.g. they claim you owe them money) the authorities will release pretty much all the information about you with the exception of 6, 9 and 11-15.

Other government agencies (besides the registration authorities) may collect, store, and use more data from you. An interesting example are the tax agencies, who can automatically obtain your records at any financial institution - without a warrant (they police themselves) or telling you or the banks.

At the end of the day you have almost as little privacy and freedom from government (and private sector) intrusion in the "holy land" of data protection rights, as you have here in database country. To some extend you might even have more freedom in the U.S., which has not only a very vocal privacy advocacy community, but has also already gone through the disaster of raging ID theft.

tag: identity, privacy, policy

I recently decided to join facebook (to be precise, right after reading Lauren's blog). So far it seems like an interesting little social tool, that benefits hugely from it wide support in the academic community.
What make facebook really interesting (in my mind) is that it is actually an application platform or - to use a now unfashionable term - a programmable portal.
THis feature really enable facebook to mash-up all kinds of services (Amazon, Dopplr, Google Maps, del.icio.us, to name a few) and present them in a fairly simple UI to users.
A downside (at least right now) in my mind is the insane default privacy settings: If you do not change your default privacy settings: If you do not change your defaults, your data is pretty much exposed to anyone, anywhere (especially since joining a regional network is rather uncomplicated). While this might have some appeal for college students, it is the single biggest issue that I have with facebook - and probably one of the most important reasons why facebook (and MySpace and other social networking tools) got a fairly bad reputation. Sharing personal information by default without EXPLICITLY opting-in is a bad thing.

Interestingly enough, you can extrapolate from facebook et al. to legal standards in general: While the U.S. has largely an opt-out approach to sharing personal information, the E.U. take a much more restricitve opt-in approach^[1].

tag: facebook, privacy, policy

[1] Except when dealing with the various governments - in that case there is pretty much no opt-out at all available for European citizens (e.g. the German GEZ will be able to get all kinds of very personal address history data from town halls and central agencies).

We all know that there is little agreement on the definition of identity, digital identity, identity (meta) system(s), user centricity, etc. There are probably as many definitions of these terms out there, as there are actors playing in this market. While many of these definitions are somewhat similar, there is still a significant semantic gap between how the various "clans" are using them and which terms are the "correct" ones: Just think about the debates around relying party, service provider, and consumer or user agent, and browser.

Traditional Digital Identity

 I would like to go back to one of the more common definitions of digital identity. For some time now, I have been operating on the notion that a digital identity is - essentially - a collection of attributes. For example, your digital identity probably has attributes such as name(s), addresses, phone numbers, email addresses, etc. The collection of these attributes - accessible in a machine processable form - constitutes a lot of knowledge about you.

On Identifiers and System Specific Attributes

While not central to the theme of this article, it should still be noted that the user name (or – more generally – the identifier) is yet another attribute in itself that might change. To limit the number of attributes, an identity system might also decide to use an existing attribute that can be taken to be sufficiently unique (e.g. an email address) for the user name/identifier.

In addition to the identifier there may be more attributes that arise through the use of a particular identity system. These can be system internal attributes guaranteeing uniqueness (e.g. GUIDs) or pseudonymous identifiers used with individual relying parties.

All these additional identifiers might be random. Yet, through their usage in the identity system they are tightly coupled to are particular digital identity and they should be treated with the same importance and privacy awareness as any other personally identifiable attribute.

Cryptography

In many cases, this collection is accompanied by some cryptographic keying material, often in the form of a public/private key pair. As the 'owner' of this digital identity, you typically have access to the private key and you can use it in transactions to prove that it is you (i.e. the 'owner' of the digital identity and its keying material) who participated in this transaction.

Derived Statements

Depending on the context of this digital identity (some people might want to call this context an identity system, federation, or identity meta-system), you [1] can create statements about your collection of attributes that do not necessarily contain all the information about your digital identity, but only a subset: for example, you might be able to create a statement about your email address and name and nothing else. Or it might be handy to create a statement about the fact that you are over 21, without disclosing your actual age or birth date.

Issues

Overall, this concept of a digital identity was - and still is - quite useful in many cases. It has a lot of built-in flexibility and can be applied to a very large number of problems.

The problem with this view is trickling up to the surface, as soon as we get concerned about the privacy of the different actors in this definition. It is quite clear [2] that within the world of this definition privacy breaches are quite easy: As soon as parts of a digital identity become known, these parts (or attributes) can be collected in databases and sold to those who are interested. This fact has already resulted in the massive disruption of email through spammers. Going forward, it is all too easy to imagine a world where private data collectors or nosy governments collect more and more attributes and information about a person's digital identity[3].

Identity By Relation

I am starting to think about identity (and in particular digital identity) in a more dynamic way:

A digital identity is a collection of relations to (i) itself, (ii) other digital identities, (iii) external entities. These relations can, but do not have to be decorated with one or more attributes.

One of the benefits of this definition is that it becomes intuitively clear that a single digital identity is not necessarily stored in a single place, but much more commonly in a number of different places. This decentralization is a crucial building block for creating a world with strong privacy by segregating as much data as possible by design. At the end of the day, it will be (almost - see below) exclusively the 'owner' of a particular digital identity that is capable to correlate across different digital identity storage locations.

With such a definition in mind, you can gather a lot of data about someone by using the identity web services of theirs, but a lot of it may be very ephemeral (e.g., their current geolocation or presence status). As such, it is actually closer to their real 'in-the-world' identity.

Correlating Through Auditing

One might argue that this separation of identity data will in turn weaken the capability to effectively correlate information about a given digital identity for legitimate purposes, in particular when it comes to requirements such as "proof of source" or "non-repudiation". These concerns can be overcome by auditing: while different storage locations are typically not capable of correlating, a concerted action (e.g. based on a court warrant or subpoena) can evaluate audit trails and construct a comprehensive image of a digital identity.

[1] More precisely: A component of the identity system can create such statements about the attributes of your digital identity on your behalf. This could be your identity provider, some active user agent, or another service separate from the identity provider.

[2] Actually from experience: probably all participants in electronic commerce or even simple electronic communication have had some of their digital identity disclosed to parties that should better not have them, e.g. spammers or worse. Frequently, this happens through the sale of this information to marketeers.

[3] This scenario applies to loosely coupled, internet-scale identity systems. In more tightly coupled systems (e.g. in internal business applications or cross-enterprise collaborations) there are usually tight governance models that regulate how data is being handled through contracts and laws.

tag: identity

Today, our OpenID provider finaly went into production. As some may have noticed, http://openid.sun.com/ has been live for some time now, and the team has been playing around with it. As of last night, we (or more precisely: Hubert) flipped the switch and we are officially live.

tag: OpenID, identity, opensource, sunopenid

You can find some information on this at the "On The Record" blog, including a link to the official text of the NAC. Now let's hope that more folks issue a similar covenant.

This time, Eve was faster than me ...

tag: Identity, OpenID, Open Source, iiw2007, sunopenid

Drummond blogged about semantically meaningful identifiers - really interesting. I particularly like his example ... and Drummond: I am perfectly happy for you to use my identifier in this example

tag: identity, XRI, OpenID

Today, we (pre)-announced at the IIW 2007 a non-assertion covenant (NAC) for OpenID. What does this mean?

First, the NAC is a short (three paragraphs) legally binding document that licenses all of Sun's patents (and not only necessary claims) to anybody for the purpose of implementing OpenID 1.1 Auth and Simple Reg 1.0 ... in perpetuity ... royalty-free. This license will only be withdrawn, if someone decides to sue Sun over this technology.As far as I know, this is the first covenant like this around OpenID.

Sun has issued already some of these - one on ODF and another one on SAML. Everytime, this prompted similar licenses and promises from other companies. Note that this move is so far totally unilateral - we (Sun) clear the way for the OpenID community as much as we can. Now it is up to other companies to do the same thing and show their commitment to the open source community.

The official announcement of this NAC will appear soon on the "On the Record" marketing blog at blogs.sun.com.

Finally, here is a picture by David showing Eve, Bill and myself making the announcement:

tag: OpenID, sunopenid, IIW2007, opensource

Here are my slides to yesterday's mini talk in the java.net community corner.

OpenID JavaOne.pdf (380.11 KB)

tag: identity, OpenID, sunopenid

I will be giving an OpenID talk at JavaOne this afternoon at 4:00pm in the java.net Community Corner in the Pavilion. In this, I will explain Sun's recent press announcement and shed some light on what we are planning to do next. Slides (and a podcast) will be available soon at the community wiki.

tag: OpenID, identity, sunopenid

Paul has a wonderful letter to Hubert on his blog ... Sorry Paul, 5 CDN will not do - but here is a web site that might help

tag: identity, OpenID, opensource, sunopenid

As a response to Johannes' post (Thanks, Johannes!), here is an unordered list of all folks that have been contributing to OpenID - Thanks to all of you:

• Hubert Le van Gong
• Wajih Ahmed
  
• Yvonne Wilson 
  
• Lauren Wood
• Rich Sharples
• Eve Maler
• Paul Bryan
• Pat Patterson
• Erica Pereiras
• Tim Bray
  
• Carolyne Wong
• Terry Palanca
• Jodie Pastor
  
• Jacki DeCoster

and many, many, more ...

tag: identity, OpenID, opensource, sunopenid

Today, Sun is announcing (Press Release) a new program to explore how OpenID can be used and utilized in a corporate environment.

As a first step, we are creating an IdP exclusively for Sun employees. What is the rationale for this, especially since there is an ever growing number of OpenID IdPs available for anybody to sign up? In principal, there is – obviously – no difference. However, the big difference is that by creating an IdP at sun.com and creating a process and policies around account this IdP, we create a trust base for relying parties: anyone accepting a sun.com OpenID authentication is assured that the holder is a Sun employee. This knowledge can be applied to customize the user experience to the Sun employee (e.g. for a special discount).

This IdP is implemented as an extension to OpenSSO/Sun Access Manager. By putting the OpenID protocol on this proven platform, we can simply extend this reliable and secure platform to new set of clients and relying parties, while offering SAML/Liberty federation and authentication from a single IdP. Today, OpenID is still simply another access protocol for relying parties, but going forward combination of OpenID with the power and capabilities of SAML will enable a variety of interesting applications. The extension is also available for OpenDS.

Over the next couple of months, we will release a number of new services and ideas around OpenID. One of the more interesting areas (I think) will be convergence and interoperability. Stay tuned!

Finally, on a personal note: I really enjoyed working with everybody on this project. Given the little time and resources I think we really got this done right.

tag: identity, OpenID, OpenSSO, opensource

The next two weeks (three weeks really) are going to be interesting: first I will present at JavaOne on AJAX interop, together with Marina Fisher. This JavaOne should get really exciting for a whole number of reasons, especially for the open source identity community ... stay tuned.

After that, Phil is inviting again to IIW 2007 which will certainly be interesting and entertaining. I promise to post frequent updates on what is going on there, as well.

tag: iiw2007, javaone, Identity, Open Source

So, here are my slides from the work shop - unfortunately the breakout session are not being webcast, so I provide the slides here.

In addition, you can find the strategic plan of the ID Theft task force here and the appendices here.

tag: Identity, Identity Theft, FTC

Today, AG Gonzales and FTC Chairman Majoras held a press conference, reporting on the progress of the ID Theft task force. The probably most interesting takeaway for me was the fact that the DoJ is creating a dedicated federal ID Theft Law Enforcement Agency. This agency will focus on ID crimes, especially cases of mass ID Theft. Along with this comes legislative initiiatives that will adjust current law to the challenges that those new crimes pose and also require federal agencies to discontinue the use of social security numbers, where possible.
This is really interesting, especially in the context of privacy and government agencies. Take the RealID act for example: in its current form and planned implementation it will aggregate a lot of consumer/citizen data in central repositories. From a privacy perspective this is not exactly ideal, especially when there are no explicit provisions in the law about protecting privacy. With the new ID Theft TF mandates itseems quite reasonable to review the current plans for the RealID implementation.
I have a little video of the press conference that I will post later.

tag: Identity Theft, FTC, Identity

Ok, I gave in. I finally registered my personal i-name. So going forward you can (also) reach me by using =beuchelt. My contact page can (obviously) be accessed by

http://xri.net/=beuchelt

Let's see how this goes....

tag: i-name, XRI, Identity

It's been a rough ride for the last couple of weeks since I had a family emergency in December and have been quite busy. Since live is coming back to normal, I will start blogging again (hopefully).

One interesting thing to mention is the Identity Landscape Paper at openliberty.org. It took some time to get this project going, but it is definitively starting to take off. So if you are interested in contributing, please let me know.

tag: Identity

OASIS has published a draft web service profile for XACML, called WS-XACML. Now, this seems to get very interesting, since it has the potential to truely deliver 'User-Centric' identity (as opposed to Infocard's ServiceProvider-centric identity).

The significant difference here is the availability of two sections in the XACML assertion: one defining the requirements, and the other the capabilities - for BOTH, server and client. InfoCard (and its implementations like Windows CardSpace or Higgins) do not really negotiate requirements, but the service provider (i.e. Relying Party) dictates its requirements and the client will only present Infocard conforming to such requirements. With WS-XACML (which - by the way - also works out-of-the-box with rich client applications) there is an initial policy matching of the server's requirements with the client capabilities AND vice versa. The superiory becomes obvious, when thinking about how easy it is with an InfoCard system to present a card with too much information.

tag: Privacy, Standards, Web Services, OASIS, XACML

This morning (PST), Roger Sullivan announced Lberty's new project called openLiberty.org. This community oriented website aims at providing developers and architects with open source implementations of Liberty's suite of identity protocols. I am really looking forward to seeing a lot of dicussion happening there.

tag: Liberty Alliance, Identity, Open Source

WS-Federation 1.1 is out... and skipping through the TOC, I have this strange feeling of deja vu.

After talking to Robin and some other folks, I think it might be an interesting exercise to define a few terms and describe how I have been using them in mny blog post. This is not necesarrily an attempt to create a dictionary or lexicon, but an explanation of how I understand things ...

• InfoCard (System): This is an authentication system, originally devised by Kim Cameron and other folks at Microsoft. It utilizes the WS-* network protocols for transport, and uses a "Wallet" metaphor for vizualizing identy information on client machines through credit card-like graphics.
  

• Windows CardSpace: By this I mean Microsoft's implementation of the InfoCard system on Windows. This includes Vista and the WCS port for Windows XP and 2003.

• IdentityCard: A single instance of an identity holding card in an InfoCard System. IdentityCards can be e.g. Higgins I-Cards holding OpenID information or Windows CardSpace cards.

• InfoCard (Card): The Windows CardSpace implementation of an IdentityCard.

One thing that I am really interesting in finding out is how (and if!) consumers will pick up on the visual IdentityCard metaphor.

I am starting this series of truly random thoughts on various identity-related topics with an area that I have - so far - not spend a lot of time thinking about: Identity for Voice. What do I mean by that?

I have my bank accounts, health care insurances (or not), credit cards, etc. Whenever I interact with these companies and organizations through a phone, they typically try to identify me by asking me questions about the identity information they have about me: PIN, social security number, birthday, zip code, maiden name of my mother, last name of my first teacher in middle school and similarly absurd questions. Based on the capability to give the correct attribute value, they consider me authenticated as "me". A local maximum of absurdity was recently reached in my digital life, when my bank switched to a system where I have to answer at least 2 questions from a list of 10, some of them as ridiculous as "Where does your next relative live?".

There are times, where things get a little more fancy. One example is using caller ID as a means to identify the phone I am calling from. Not only is it quite dubious in my mind that this is a good way to authenticate. Even worse is the fact that there are plenty of ways to fake the caller ID system.
Beyond that, we also have voice recognition (which might get quite good), but there is always the option of a tape recorder and voice synthesization technology. Also, there are call-back mechanisms.

Another problem is the potential for phishing through voice based systems. To address this, there would need tobe a way to authenticate the provider (i.e. the bank, insurrance company, etc.) to the caller, which is - to my knowledge - not easily possible at all at this time.

Quite obviously, I am not really happy with identity in voice UI land. While this might be ignorance on my part (there have to be quite a few folks out there thinking about solutions to this problem), I think that the distributed-services-and-federated-identity crowd that I am working with mostly, is equally disconnected from these problems.

So what can we do about this? First of all, get smart about the the voice ID problems. I have started to talk to a friend of mine working in this area, and he gave me a lot of interesting entry points into the world of voice UI. Beyond that, I suppose we might have quite a few ways to extend security:

• Integrated multi-factor authentication: Voice print, caller ID, call back and attribute knowledge are - by themselves - insufficient. A combination of these might be sufficient for low risk transactions.
  
• Increased integration of electronic and voice technologies: Authentication could be done through a web site (based on strong crypto). The web site would then issue a single use, time limited password, that would serve as an additional authentication factor. There are quite a few technologies available today that I would put into this category, including SMS based authentication schemes for cell phones.
  
• Better Meta Data with each call: If we could transmit meta with each call (e.g. proof of posession of a private key), we would immediately increase the level of trust I could have in a voice communication. While traditional telephones do not offer any reasonable extension points, cell phone or - eve more so - VoIP system can send additional data through a data channel.
  

An additional meta data channel with each call would be - as far as I am concerned - the best solution.  This would allow us to tie the authentication for the voice UI into cryptographically strong identity techniques.

James McGovern asks whether federated identity might require (at least sometimes) federated authorization. I think this is a pretty good question and one that is not easy to answer. My initial take on this would be that federated identity should not require federated authorization, assuming that I understand correctly what federated authorization really is.

For simplicity's sake, let identity be just a bag full of attributes (e.g. e-mail address, names, phone number, etc.). An indentity provider is then nothing more than a service that asserts that certain attributes have a particular value for a given digital identity. A relying party (i.e. a service provider like e.g. AmazingBookStore) can choose to trust such an assertion - either in full, or just certain parts of it. At the end of the day, the relying party will have to determine the level of access based on the type of assertion and the content of the "attribute bag". As such, in this case authorization is local.

If authorization is to be delegated to another point (as in e.g. the XACML model), the relying party forwards it to a policy decision point, where the contained attribute information and additional attributes the PDP might obtain are evaluated according to a set of policies.

Now what is federated authorization? If I understand it correctly, it would be a scenario where you trust access level decisions to your resources to a third party (e.g. you would let YahaPortals.COM decide whether or not a user can get access to data you own). I am tempted to say that the risk that YahaPortals has about a false negative or false positive decision is quite substantial, particularly in our age of increased liability.

While there might be some use cases that do (or will) require such a model, I would argue that XACML provides a pretty substantial technology base for a federated authorization system, should the need arise. Some additional elements for such a system (e.g. trust establishment, crypto, etc.) could be either profiled or application specific.

UPDATE: As usual (at least in the last couple of weeks), I am quite behind things. James apparendly commented on quite a few blogs (hmm, was that related to IIW tagging ... noooo, can't be) and got some pretty substantial answers from Pat, Conor, and Paul.

After suggesting the general OSIS session at IIW, I obviously was obliged to run the session as well. Overall, I think that the session was sucessful - although I believe that only those that have been working in the context of OSIS for a while have been really satisfied.

One of the things that have been requested during the session was a somewhat comprehensive, yet high-level overview of the OSIS "sector" of the identity landscape. I tend to agree. While those that have been involved in OSIS  and some of the projects associated with OSIS are starting(!) to get some shared understanding of what OSIS is about and how things relate to it, many people in the industry just don't. [1]

Unfortunately, we did not have the time to "bash" Johannes' overview talk on OSIS, which I found to be a reasonable first introduction.

So allow me to making an attempt to clarify the "elevator pitch:

OSIS is a - intentionally - fairly informal working group under the newly formed identitycommons. Its short term goal is to facilitate the creation of an InfoCard compatible client that is fully interoperable with Microsoft's Windows CardSpace implementation. Down the road - as soon as we can present some tangible results on our first goal - we intend to broaden the scope and will include OpenID, Liberty and other open source identity technologies to create an open and interoperable general purpose identity SYSTEM.

The way to achieve these goals (i.e. the facilitation) is by providing a place to discuss the needs, status and goals for all OSIS projects. In particular, OSIS will not:

• create profiles or standards
• attempt to force its consituents to develop into a certain direction
• provide a comprehensive administrative and legal framework

The biggest value-add of OSIS to me is its informal participation structure: this allows a fairly free flow of ideas between technologists that are trying to get things to work with each other. Politics and religion stay (largely) out of this by design.

[1] Yes, OSIS does have a charter under IDcommons. However this charter is not really a good high-level overview in my opinion. In fact, the charter really underlines the informal character of the group by being *really* open-ended.