I2-Barcelona
OSIS Interop Event 2, Barcelona, October 23, 2007
Contents
Overview of OSIS
Summary of OSIS goals from the [draft OSIS Project Plan]
- Provide a forum for implementors (as opposed to standards developers etc.) of parts of the internet-scale identity layer to coordinate making their respective parts work together; the internet-scale identity layer is only possible if as many parts as possible are interoperating. This includes identifying and discussing issues, and resolving conflicts.
- Operate the necessary infrastructure to do so, including wikis and mailing lists, teleconference calls and in-person meetings as needed.
- Collect, document and make broadly available a knowledge repository including best practices for the implementation of such parts and interfaces, the different protocols available, and vendor support of these.
- Develop, collect, document, and make broadly available test suites and test sites that can be used as references for developers and implementors.
- Identify, collect, and make work identity interoperability use cases.
- Identify business/customer needs, articulate them publicly and use them as the driver for business-relevant use cases.
- Define “interoperability profiles” of one or more identity standards in order to accomplish particular interoperability use cases that developers can test towards and customers can compare.
- Conduct additional interoperability events, broadening the scope from WS-* to OpenID and other protocols.
Structure, Process, Roadmap and Deliverables
This interop event should have a name. This document proposes the working title of "OSIS I2 Barcelona", although something like "Barcelona Bakeoff" or, perhaps, a humorous name would work as well. We should agree on a final name by the DIDW meeting (see below).
This page will summarize the goals of the I2-Barcelona interop profiles. In particular there is a section that will describe or link to user scenarios and business value of the identity systems. These can be high-level descriptions that give a sense of how the specific interop profiles are of value to people and businesses. Specific interop profiles should be able to be tested by implementations. An implementation should be able to objectively state that it supports a profile.
To structure project interactions there will be three matrices: one for Relying Party implementations, one for Identity Providers, and one for Identity Selectors. Each page should specify an interop profile for each row (with a link to detailed information about the profile). The columns will indicate implementations and current status for each profile. The detailed information about each profile -- likely a page in this wiki -- should include information about reference sites that can be used to test an implementation's support (when possible).
Roadmap and deliverables:
Complete first phase by Sept 24:
- decide on interop profile group name, (print t-shirts ;-) )
- complete user scenarios
- complete set of interop profiles
OSIS meeting at [Digital Identity World conference], Sept 24-26
- working meeting to debug implementations and profiles
- gather status and plan for Barcelona
Concluding event at the [Burton Catalyst conference] in Barcelona, Oct 22-25.
- Event information and logistics for registering
- Demonstration room information at the Hotel Rey Juan Carlos
- Logos: Current version of handout and banner
By Oct 30 each project is asked to complete an interop profile set report that can aid in planning for the next one.
- what worked and didn't work in the event structure
- specify profiles supported
- suggested areas to focus on for the next Interop Scenario Group
Coordination and Development for this interop profile group is intended to be in line with the [OSIS communications plan]. Communication and coordination is encouraged to be public.
- the main communications channel is via the [I2-Barcelona mailing list]
- discussion also happens at the DIDW meeting listed above.
- conference calls for the overall OSIS working group are announced on the [OSIS general mailing list]. They are currently weekly, Monday noon Pacific time.
User Scenarios and Interop Goals
Note that this section is (so far) very incomplete and will be developed by the OSIS working group until the milestone listed above. This section will be statement of user and business goals -- something like "themes" for the profile set.
Refined Information Card Protocol Support
- determine best practices for handling incompletely specified interactions in token formats and encoding
- error handling and abuse cases
- more token types
Component Packaging
- platform coverage
- installation instructions and support
- co-existence and clean uninstallation
Identity System Integration Points
- use an Information Card to authenticate to an OpenID OP (same as last interop, just repeat more loudly).
- Particularly I'd like to show that it works to login to an OpenID Provider using an Information Card and then having this information conveyed via PAPE (http://openid.net/specs/openid-provider-authentication-policy-extension‑1_0‑01.html) so that the OpenID Relying Party will know that the user used phishing‑resistant authentication at their OpenID Provider.
- [OpenID token type]
Interop Component Types
Relying Party Profiles and Participants
See Relying Party Profiles and Participants
Identity Provider Interop Profiles
See Identity Provider Profiles and Participants
Identity Selector Interop Profiles
See Identity Selector Profiles and Participants
OpenID Provider Interop Profiles
See OpenID Provider Profiles and Participants
OpenID Relying Party Profiles and Participants
See OpenID Relying Party Profiles and Participants
Results
Unresolved and Unplaced Profile Issues
Not sure what to do with these. Many of them are good goals, and perhaps should go in the goals section. Some seem to be more profilish but it is often not clear (to me) how they can be stated such that they are implementable in an objectively measurable manner. Some are just insufficiently specified.
- Some RPs required installation of a certificate on the Identity 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.
- 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.
- WS‑Trust 1.3, WS‑Policy 1.5, WS‑SecurityPolicy 1.3, WS‑Addressing 2005, SOAP 1.2, etc.
- Cell Phone Based IdP
- Transport Bindings, +Symmetric + Asymmetric Key Bindings
- CardSpace compatible PPID, Friendly PPID, and SS‑Key Gen
Participants and Contact Information
Each participant should list a link to more project information and contacts, any download locations, and endpoints to be used for testing.
| Project Name | Endpoint | Contact Info | Logo | Present in Barcelona | |
|---|---|---|---|---|---|
| VeriSign | PiP | Roxana Bradescu | contact me | yes / not staying in conference hotel | |
| CA | SiteMinder RP | Jeff Broberg | 
|
No, however other CA individuals will be there. | |
| Bandit | Trac RP | Duane Buss | tbd | No, however other Bandit Project members will be there. | |
| Bandit | WordPress RP | Tom Doman | No, however other Bandit Project members will be there. | ||
| Bandit IdP | Bandit Wag IdP | Daniel Sanders | tbd | No, however other Bandit Project members will be there. | |
| Bandit IdP | Bandit Cards IdP | Daniel Sanders | tbd | No, however other Bandit Project members will be there. | |
| Ping Identity | https://labs.pingidentity.com | Ashish Jain | tbd | No | |
| Higgins | Web-based Selector | Charles Andres Markus Sabadello | contact us | Yes; not staying in Conference Hotel | |
| Higgins | Higgins RP | Bruce Rich Tony Nadalin | tbd | Yes | |
| Higgins | Higgins IdP | Mike McIntosh Tony Nadalin | tbd | Yes | |
| Higgins | Eclipse-based Selector | Tony Nadalin | tbd | Yes | |
| IBM | IBM IDP | Shane Weeden, Tony Nadalin | Tony, yes. | ||
| IBM | IBM RP | Shane Weeden, Tony Nadalin | tbd | Tony, yes. | |
| FuGen | FuGen RP, FuGen IdP | Vijay Simha, Lena Kannappan | tbd | No, but we will have representation. | |
| JanRain | MyOpenID IdP, OpenID Implementations | Josh Hoyt, Kevin Fox | n/a | No | |
| Microsoft | Numerous | Mike Jones, Vijay Rajagopalan, Samuel Devasahayam, Steven Woodward - feedback to fedid@microsoft.com | tbd | yes | No, but we will have representation. |
| Pamela Project | PW Wordpress RP | Pamela Dingle (first name AT nulli DOT com) | tbd | no | |
| Siemens AG | DirX Access | Wolfgang Roth | logo | yes | |
| WSO2 Identity Solution | WSO2 Identity Solution IdP | Ruchith Fernando Dumindu Pallewela | logo | yes, Paul Fremantle | |
| WSO2 Identity Solution | RP Apache2 Module (mod_cspace) | Ruchith Fernando Dumindu Pallewela | tbd | yes, Paul Fremantle | |
| WSO2 Identity Solution | Java RP | Ruchith Fernando Dumindu Pallewela | tbd | yes, Paul Fremantle | |
| OpenSSO | TBD | Gerald Beuchelt beuchelt at sun.com | logo | Yes: Mrudul Uchil, Sun Microsystems | |
| Oracle RP | Oracle Photoshare Application | Ramana Turlapati Eric Lam Andrew Maywah | 
|
No |
