Burton Group Identity Blog

OSIS User-Centric Identity Interop at Catalyst Europe 2007

Blogger: Bob Blakley

OSIS conducted the third in their series of User-Centric Identity Interop events yesterday at our Catalyst conference in Barcelona.  As we did in San Francisco, Burton Group hosted and provided support for the event.

There were a few differences between the Barcelona interop and the earlier event held at Catalyst North America 2007.   The most noticeable difference is that the Barcelona interop has been conducted entirely in public.  You can visit the Interop wiki to see details of the organization, planning, use cases, and participants; if you’re in a hurry, though, I’ll summarize here.

Fourteen projects and organizations participated; you can see the list here.

The participants tested 6 identity selectors, 13 identity providers, and 24 relying parties.  The Barcelona interop added a significant amount of testing of OpenID interoperability; 6 OpenID providers and 5 OpenID relying parties participated.

The participants have posted their results on the wiki, and a few words are in order about these results.  The first thing you’ll notice is that there are a significant number of “failure” and “issue” results.  This is very good news for two reasons.

The first reason it’s good news is that it means enough new test cases were designed for this interop to uncover new problems.  What you don’t see in the matrix is that when testing began, there were even more failures – which means that a lot of the new issues identified during the exercise have already been fixed.

The second reason the “failure” and “issue” results are good news is that they’re outnumbered by the successes.  When you consider that the things tested in Barcelona were all identified as problems at the previous interop, you’ll get an idea of how much work has been done by the OSIS community in only 4 months to improve interoperability and agree on standards of component behavior.

I’d like to call your attention to one more thing.  At the Catalyst North America interop in San Francisco, all the interop participants were onsite, sitting in a room together.

Here in Barcelona, as you can see in the Participant Profile table, about half the participants worked remotely.  What this means in practical terms is that a lot of the components in this interop were accessed over the Internet, in the same configuration you’d use if you deployed them in your business.

I expect that the results table will continue to evolve for a while as additional information from the event is digested and entered into the wiki; I’ll probably post another blog entry with some analysis of the significance of the results after the conference is over and I’ve gotten some sleep.  But my preliminary sense is that this interop continued to demonstrate progress toward an open, deployable, interoperable identity metasystem.

I’m grateful to all the participants for their hard work, and I hope the next interop moves the ball even further forward. Also, we thank Microsoft for sponsoring the sponsoring the network connectivity as well as the catering for this event.

Meta Madness

Blogger: Bob Blakley

Paul Madsen, commenting on my recent post regarding the Catalyst user-centric identity interop, argues that the event didn’t demonstrate the existence of a metasystem.  Robin Wilton agrees with him, as does Gerald Buechelt, who adds his criterion for what would constitute a metasystem:

“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.”

Even if it were true that there was only one protocol demonstrated on the wire at the Catalyst interop event (which it is not; for example, a variety of different protocols were used to authenticate Identity Selectors to IDPs), I reject the assertion that you can’t have a metasystem without protocol diversity.

It was not a longing for different bitstreams on the wire which gave rise to the desire for an identity metasystem – it was a real honest-to-God human need: “I want to be able to visit different sites without having to create a new account at every site, and I want to do this in a way which doesn’t involve publishing everything about myself to everybody in the world”.

Meeting this need required the identity community to invent at least one set of protocols which enabled different identity systems (not “protocols”) to work together to allow users to carry their identity information around with them.

The fact that it ties multiple systems together is why it’s called a meta-system.  Notice that it’s not called a “meta-protocol”.

At the Catalyst interop event we saw users exporting managed cards from different Identity Provider systems into the same Identity Selector system.  We saw users using cards from the same Identity Provider system with different Relying Party systems.   We saw users authenticating to different Identity Provider Systems with the same (OpenID) credential.  We saw several configurations of these components working together with no Microsoft CardSpace components involved at all.

If the Liberty community and the WS-* community want to keep arguing with one another about whose protocols need to be in the mix before we call that mix a metasystem, I suppose there’s nothing that can stop them from doing that.  But the argument doesn’t help actual people or actual businesses get any interesting work done.

The participants in the Catalyst interop did help actual people and actual businesses get interesting work done.  That’s why OSIS is organizing more interops in the future; bringing Liberty-compliant components to these events and working with the other participants to make them interoperate with everyone else’s technologies would be much more useful than whining about how many protocols must dance on the head of a pin before we’re allowed to call it a meta-pin.

Incidentally, as both Gerald and Jeff Bohren note, the Catalyst interop was the second such event OSIS has organized.  I mentioned the first – held at IIW 2007a – in my initial posting.  I participated in the IIW inteorp and did not summarize it here only because Dale Olds has already posted an extensive and excellent writeup of the event.

Recapping the Catalyst user-centric interop

Blogger: Bob Blakley

The Burton Group hosted a User-Centric Identity Interop at the Catalyst Conference in San Francisco during the week of 23 - 29 June 2007; a public demo session was held on the evening of Wednesday 27 June to showcase the accomplishments of the participants in this event.

The interop event was a milestone in the maturation of user-centric identity technology.  Prior to the event, there were some specifications, one commercial product, and a number of open-source projects.  After the event, it can accurately be said that there is a running identity metasystem.  This identity metasystem is not grown up yet, and it still suffers from a number of issues.  But a lot of issues which used to exist have been fixed as a result of the efforts of the interop participants leading up to the event, and many more issues which were previously unknown have been identified and are being worked.  Many gaps in the user-centric identity and information card documentation have been identified and some have already been filled.  Microsoft's Open Specification Promise documentation set has been augmented with new material essential for smooth multi-vendor (or multi-project) interoperability.

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.  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.  The interop participants, recognizing the accelerant effect the Catalyst event has had on development of their technologies and products, are planning a series of future public interop events, some at Burton Group events and some elsewhere, to maintain the momentum they have built by participating in the Catalyst event.

PARTICIPANTS

24 organizations and individuals participated in the interop event; in alphabetical order they were: the Bandit project, BMC Software, Ian Brown, CA, FuGen Solutions, the Higgins project, IBM, Internet2, Microsoft, NetMesh, the Pamela Project, Oracle, Ping Identity, Sxip Identity, Verisign, WSO2, and XMLDAP.org.  This list includes for-profit corporations, open-source projects, and individuals.

The user-centric identity architecture includes three types of components: Identity Selectors (which allow users to select information cards and thus control which  claims are distributed to other parties), Relying Parties or RPs (which consume and rely upon claims to grant access and authority to users), and Identity Providers or IDPs (which manage user identity information and distribute it to RPs).

The participants brought 7 Identity Selectors to the interop event:

• 3 Higgins selectors

• Ian Brown's Safari plugin selector

• the Microsoft Windows Cardspace selector

• an early version of an upcoming version of the Microsoft Windows CardSpace selector

• the XMLDAP.org selector.

12 Identity Providers were tested during the interop event; again in alphabetical order, these were:

• Bandit Wag IDP

• FuGen's Test IDP

• the Higgins IDP

• IBM IDP

• the Internet2 Shibboleth IDP

• Kim Cameron's Identityblog HumanPresent IDP

• Microsoft Age STS IDP

• Microsoft's Windows Live Labs IDP

• the Ping Identity SignOn.com IDP

• the Verisign IDP

• the WSO2 IDP

• the XMLDAP IDP

25 Relying Parties were tested during the interop event; these were:

• 2 Bandit RPs

• the BMC RP

• the CA RP

• the FuGen Social Photos RP

• the Higgins RP

• the IBM RP

• the Internet2/University of Washington RP

• 2 Kim Cameron Identityblog RPs

• 2 Windows Live Labs RPs

• the Microsoft Age STS RP

• the Microsoft Fabrikam Friends RP

• the NetMesh RP

• 2 Pamela project RPs (one for Joomla, one for Wordpress)

• the Oracle RP

• the Ping Identity RP

• the Sxip Access RP

• the Verisign RP

• 2 WSO2 RPs

• the XMLDAP RP

• the CardSpaceDemos.com FriendsWithCards RP

RESULTS

The interop clearly showed that Microsoft's decision to open the information card specifications, combined with the identity community's enthusiasm for user-centric identity technologies, has resulted in a truly open environment with lots of innovation and a variety of commercial and open-source providers.

Two scenarios were tested:

1. Identity Selector imports managed information card from Identity Provider

2. Identity Selector logs user in to Relying Party using information card

    2a. using a self-issued information card
    2b. using a managed information card obtained from an IDP via scenario 1

Some Relying Party sites implemented customized content or behavior which was triggered based on claims generated by IDPs and consumed by RPs.

Many combinations of Identity Selector, Identity Provider, and Relying Party were tested - exact statistics can't be compiled because record-keeping during the event was not completely systematic.  Most tested combinations worked successfully in both scenarios.

Many issues were identified during the two months leading up to the Catalyst interop event, and most of them were fixed.  Vendors and open-source projects worked hard and they worked well together. 

Most of the issues identified arose from the usual sources: underspecification of namespaces, schemas, required and optional protocol elements, algorithms, and encodings; the next section ("ISSUES") enumerates the most important of these issues. Given the relative youth of the specifications and the explicit WS-* philosophy of trading off in favor of extensibility and flexibility and against completeness of specification, the existence of these issues is not surprising.  However it's also important to note that most of these issues will be easy to fix via profiles and additional specification detail. 

A few more serious issues arose also.  It became clear during the preparation for the interop that the trust semantics of IDP assertions are not yet firmly established; RPs need to be able to know what to expect when they consume an assertion from a new IDP, and this will not be possible until rules of trust are written down.  Interactions between users and RPs is also not yet sufficiently standardized.  Users who visit multiple RPs will need to be able to understand the icons they see on RP screens, and to understand in advance what behaviors to expect when they select those icons.  Some RPs require the use of encryption technology which is encumbered by international deployment restrictions.  Finally, it is not clear how the namespace of claims communicated from IDPs to RPs should be organized and governed.

ISSUES

Claim validation

• It became clear during the run-up to the interop that no standard set of token and claim validation procedures had been defined for RPs.

• Matching rule issues caused some failures (for example, is a URL with an appended "/" the same as or different from the same URL without the "/"?)

Claims and claim namespaces

• Some RPs rejected claims because they did not recognize the claim namespace generated by the IDP.

• Some RPs rejected claims because of case-sensitivity issues.

• The handling of claims with multivalued attributes appears not to be fully specified

• The semantics of an IDP issuing a claim are not clear; in particular it is not clear whether creation of a signed token containing a claim constitutes a statement by the IDP that it believes the claim is accurate.

Required and supported claims

• Some RPs required an exact match of required claims and presented claims; other RPs matched if required claims were a subset of presented claims.

• Some IDPs generated tokens with claims not requested by the RP; the consensus was that IDPs should not generate claims which do not appear in the RP's list of required or optional claims, because of privacy concerns.

Card Acquisition

• Card creation varies from IDP to IDP, and is in many cases primitive from a human-factors point of view.

• Procedures for importing cards are also not standard and are in some cases complicated or confusing.

Encoding

• SAML token version requirements are underspecified; IDPs and RPs need to be able to agree on the supported token versions.

• Base-64 encoding issues caused some failures due to incompatible assumptions about where line breaks may legally occur.

• Some RPs rejected claims because of ambiguities in what token information was to be included in the scope of hashes in signed tokens.

• Some RPs encountered issues with XML canonicalization of tokens.  Use of a standard canonicalization library may be desirable.

• Some issues were encountered with how plaintext data was padded prior to encryption.

• SOAP versioning (1.1 vs. 1.2) caused compatibility issues.

Certificates and Keys

• Some RPs required installation of a certificate on the selector machine.

• Certificate path validation is handled in a variety of ways by RPs; some RPs experience serious performance problems due to path validation.

• Introduction behavior is not well-specified; when an RP encounters a token from a previously unseen IDP which is not in an administered trust list, no standard behavior is defined.  Most RP failure modes provide little information to an administrator who might want to add the IDP to a trust list.

• Using EV Certificates requires complicated configuration.

Encryption algorithm support (and export restrictions)

• Some RPs could not decrypt tokens because they lacked support for the encryption algorithm used; furthermore, since the failure resulted from inability to  use 256-bit AES encryption, which is subject to US export controls and other international deployment and use restrictions, this problem may not be straightforward to fix.

Time

• Some RPs rejected assertions because of issues with synchronizing clocks between IDPs and RPs.

• When self-issued cards are used, time synchronization between the client machine running the Identity Selector and the RP server can cause failures.  Since client machines are less carefully administered than IDP and RP servers, this may prove to be a difficult issue.

Presentation

• Neither selector behavior nor RP behavior is standardized; it is not straightforward for users to know what to expect when using information cards with different selectors, or with the same selector but a variety of RPs.

• It was observed that some RPs are using different approaches to detecting and triggering identity selectors; this caused some failures.

• Some RPs exhibited different behavior on first visit (required registration of some sort) versus subsequent visits.

MOVING FORWARD

OSIS, a working group of Identity Commons, is already working on future interop events; the Burton Group and many of the interop participants working to host another interop event at the European Catalyst conference in October in Barcelona.

OSIS is also considering a number of other initiatives which should improve interoperability and usability of user-centric identity technology.  These include claim schema standardization, documentation of user-centric identity, OpenID, and information card best practices for Identity Selectors, Identity Providers, and Relying Parties, test suites for user-centric identity components, and interoperability profiles for user-centric identity components.

Active discussion of interoperability issues continues on the OSIS mailing list.

THANKS

Finally, a number of organizations and individuals deserve special thanks for their part in the Interop event.  Oracle contributed the monitors which were used to demo the technology to Catalyst attendees.

Johannes Ernst and NetMesh contributed the Wiki which was used to plan and administer the interop event.

Mike Jones of Microsoft not only devoted significant amounts of his time to the interop event but also moved heaven and earth at Microsoft to ensure that all the intellectual property needed to make the interop possible was included in the Open Specification Promise document set.  Microsoft also sponsored both the network and the catering for the interop event.

Pamela Dingle of Nulli Secundus and the Pamela Project devoted a significant amount of time to defining the interop scenarios and also helped organize the IIW interop which paved the way for the Catalyst event.

Dale Olds of the Bandit project sponsored the interop event; he also designed the illustrated brochure  which advertised it to Catalyst participants (a lot of work) and paid for the printing of the brochure.  Finally, Dale collaborated with Pamela on the organization of the IIW interop event.

Ping Identity sponsored a much-needed after-party for interop participants.  IBM, courtesy of Tony Nadalin, co-sponsored this party, as did we.

A Day in the Life at Catalyst ‘07

Blogger: Mark Diodati

Many of our customers tell us that their Catalyst experience is jam-packed, enjoyable, and satisfying.  At Burton Group, we feel exactly the same way.  We also experience a little euphoria after the conference, as we have been preparing for months for the event.  Thursday, June 28, was a satisfying day for me.

7:00am – 8:15am. Lori, Kevin and I have a breakfast meeting with the participants of our Policy and Privilege Management (PPM) session.  Burton Group is trying a new time-compacted, multi-speaker format.  Because there are six participants (excluding Lori, Kevin, and I), we want to review the logistics of the session.  We also want to re-emphasize the virtues of brevity as we are concerned about running over schedule.  The PPM session has three subtopics (role management, entitlement management, identity audit), with a customer and industry participant for each subsection.  Lori and Kevin are a pleasure to work with.  The IdPS analyst team gets along very well, and works well together.  I have three Diet Cokes before the PPM session begins.

8:35am – 10:20am.  The PPM session goes well.  Debbie Cuadros provides an engaging story about DIRECTV’s roles deployment that is well-received by the audience.  For the entitlement management subtopic, I briefly present an overview on entitlement management, then host Timothy Moore (First American) and Brendon Unland (Jericho Systems), who provide the customer and industry perspective.  To our amazement, everyone sticks to the schedule, and we have time for questions at the end.  Overall, I am pleased with the session format, and I document some session-improving thoughts for the IdPS analyst post-mortem meeting in July.  I have another Diet Coke during the session.

10:40am – 11:50am.  I listen to the presentations from Joe Long (Microsoft) and Ranjan Das (SAP).  I also review my PowerPoint slides for my afternoon presentations.

12:10pm – 1:40pm.  I meet with Diana at the local Starbucks for a final review of our PCI-FFIEC session.  It’s not all work and no play.  Diana and I are good friends, so we have a few laughs and catch up a little.  The walk between the Hilton and Starbucks seems particularly refreshing, and I realize that I have not set foot outside the Hilton in two days.  Before Diana and I head back to the hotel, I order my second Venti Mocha and quickly dismiss the passing thought that I might have issues with the demon caffeine.

2:05pm – 2:25pm.  Jamie gives the keynote presentation for the Infrastructure Services Model (ISM) sessions.  These sessions cut across our Application Platform Strategies and IdPS services.  Jamie does a great job of speaking to this diverse audience and setting up the upcoming ISM sessions.

2:25pm – 2:50pm.  I deliver my identity services presentation, and then call up the identity services panelists.

2:50pm - 3:50pm.  I host the identity services panel.  We have great panelists, and our dialogue goes very well.  Don Bowen (Sun), Bill Dettelback (BEA), Phil Hunt (Oracle), Nick Nikols (Novell), and Andy Rappaport (CA) all do a great job.  The dialogue is insightful, free of vendor market-speak and sniping – due in no small part due to the expertise and professionalism of the panelists.

4:10pm - 4:45pm.  Diana and I deliver the PCI-FFIEC presentation.  She’s a great speaker.  Before we present, I have a sugar free Red Bull.  I reasonably conclude that I have a caffeine problem.

4:45pm – 5:50pm.  I listen to Bob’s panel on compliance orchestration.

6:20pm – 9:45pm.  I run into Trent, Eric, and Pete early on at the hospitality suites.  Trent, Eric, and I are friends and share a similar sense of humor.  Pete is relatively new to Burton Group, but I think he’ll fit in just fine.  I have my first of a few alcoholic beverages since arriving at Catalyst.

10:00pm.  I head back to my hotel room after a very satisfying day.  I play guitar for a little while, then go to sleep.  I have four customer meetings tomorrow, starting at 7:00am.

Concordia meeting at Catalyst

Blogger: Gerry Gebel

We played host to the latest Concordia meeting earlier this week at Catalyst. It's been so busy, I'm just now getting around to posting a few comments. Others have published some excellent observations here, here, and here.

At the meeting, end user organizations (AOL, Boeing, GM, Gov of British Columbia, and GSA) described usage scenarios, highlighted key requirements, and offered sage advice to the standards development and IdM product communities. What a concept - injecting real user requirements into the standards process! Let's just say that more interaction is needed between producers of standards and products - and the organizations that buy and deploy them. There was a lot of commonality of requirements between the presenting organizations that remain inadequately addressed. You can see these requirements posted here.

Thanks to the Concordia team for holding their meeting at Catalyst, it surely enriched the conference.

Time for an XACML interop demo? YES!

Blogger: Gerry Gebel

In February, we prodded the vendor community to meet the challenge of conducting an interoperability demonstration for XACML. We're happy to report that the OASIS XACML Technical Committee responded by creating an interoperability project team, consisting of BEA, CA, IBM, JBoss/RedHat, Jericho Systems, Oracle, Securent, and Symlabs. This ambitious group of vendors has been working over the past several weeks to create and test a number of interoperability scenarios that will be on display in 2 weeks at the Catalyst conference. The use cases scenario document is available at the XACML web site. On our recent TeleBriefing, Hal Lockhart and Rich Levinson explained what is happening at the event and the podcast is available here.

With a growing interest in XACML version 2.0, which was published more than 2 years ago, it's great to finally have a public interoperability demonstration. To set expectations, this demonstration event will not guarantee interoperability for all XACML-based products, but it will give an indication of maturity for the industry. After the conference, we'll interview all the participants and document the project in a summary report for Burton Group clients. However, we encourage you to attend the conference to see the demonstration first hand on Thursday evening, June 28. It's your opportunity to ask the vendors detail questions about the interop scenario - and how this standard may apply to authorization scenarios in your own environment. See you there!

Proposed WSFED Technical Committee: Divergence Point for Federation?

The March 20 announcement proposing a charter for a new OASIS Technical Committee for WS-Federation is rekindling a fire that has been smoldering for some time. Many a debate occurred at Catalyst and in other forums as to the merits of the WS-* long-term vision for web services security vs. SAML’s immediate focus on browser-based federation scenarios.  A common theme to these debates was a call for convergence of SAML, Liberty Alliance, and WS-Federation efforts. Meanwhile, vendors staked out positions regarding SAML, WS-Federation, and Liberty Alliance. Microsoft has held its ground in withholding support for the SAML protocol. IBM straddled the fence after initial reluctance to support Liberty ID-FF, ultimately supporting standards and specifications as demanded by customers. Most other vendors in the federation space hedged their bets by grudgingly supporting multiple protocols and specifications.

As Yogi Berra would say, “It’s déjà vu all over again.”

Nearly two years ago, Burton Group published a report titled “SAML 2.0: Convergence Point for Browser-Based Federation.” It contained the following statements, “Security Assertion Markup Language (SAML) 2.0 represents a watershed moment for federation standards because it combines the efforts and features of SAML 1.x, Liberty Alliance Identity Federation Framework (IDFF), and Shibboleth” and “OASIS may also attempt to foster more convergence for browser-based federation by working with the supporters of WS-Federation passive profile (WF-PP).” Obviously, this is not the case. Several have commented on the TC proposal, including Nokia, France Telecom, NTT, Sun, Oracle, and Neustar. In addition, Tim Bray posted a rip on his blog. 

The WSFED charter gives lip service to working on convergence with SAML 2.0. Like other commenters, we find this less than convincing; the WSFED charter's invitation to other standards committees looks like a passive-aggressive maneuver. It puts the onus on SAML 2.0, which has already been standardized, to come to WSFED on their terms and make changes to an established standard to accommodate features of a specification which was not developed in an open forum and is not yet a standard.

In 2004, we wrote “The industry is showing signs of concern over standards convergence, but having two standards for federation and SSO is better than having 20, or zero. It is likely the market will need more than a one-size-fits-all standard and one can hardly imagine any single standard fitting every scenario, regardless of its composability. “ Well, it looks like convergence is going to resurface as an issue, particularly when there is so much overlap between SAML 2.0 and the proposed WS-Federation work.

If Microsoft, et al, were to merge the WS-Federation passive profile with SAML 1.x and then focus this TC on the active profile – that would clear up a lot of confusion and limit redundancy.

What happens next?
•    OASIS has scheduled a call to review the proposed charter on April 5th. OASIS members are permitted on the call.
•    Post your comments here or elsewhere to have your opinions heard
•    Shameless Catalyst plug: attend the conference this year where much of day 1 is dedicated to the identity interoperability discussion

[posted by Gerry Gebel, after much discussion on an internal email thread]

Is it a Matter of Secrecy or Privacy?

Bob Blakley just posted an entry called The End of Secrecy on the new SRMS blog - a topic that will receive considerable attention at the Catalyst conference this year. The Day 3 agenda for the IdPS team focuses on “Digital Identity: Implications for Policy and Society.”

As society grapples with the use of identity in consumer activities, Internet commerce, and social programs, enterprises may at first seem shielded from the outcome of such issues. But enterprise identity and Internet identity are quickly merging into a common problem space. As consumer- and citizen-facing identity systems are refined, they will heavily influence the way enterprises issue identifiers, manage personal information, and federate with other businesses. Similarly, enterprise technologies bring a wealth of experiential information to the design of internet-wide identity systems.

We hope to see you there to participate in and contribute to this conversation.

[posted by Gerry Gebel]