I2-Barcelona

From OSIS Open Source Identity Systems
Revision as of 23:52, 26 August 2007 by http://olds.myopenid.com/ (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

OSIS Interop Event 2, Barcelona, Oct 2007


Overview of OSIS

As per the OSIS project plan (Johannes Project Plan sent to OSIS mailing list Aug 2007

  • 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.


Roadmap and Deliverables

set of 3 matrices

   title is Interop group (I2-Barcelona) and RP, IA, or IdP
   rows are links to interop profile
   column is project
   filled in is intent to complete profile
  

Scenario specification deadlines informal working session DIDW concluding event in Barcelona project report:

   what worked
   what didn't
   suggested areas as input into next Interop Scenario Group

Communication plan

   purpose of this document
   link to Pam's communication page
   mailing list (with reply-to-list as default)
   project participants and scenarios  

User scenarios and Interop Goals

statement of user and business goals

then break out into IP, IA, RP pieces.

   specify a best practice, e.g. RP selector invocation or RP token validation steps

a) refined information card protocol support, with error handling and abuse cases

b) component packaging (platforms, installation, co-existence)

c) identity system integration points

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. (David)


Interop Profiles

Relying Party Interoperability Profiles

Token and claim encoding and validation procedures

Perhaps these can be broken into token encoding profile (IdP's need to know), and transport profile (IA's need to know),

  • 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. (Bob)
  • 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 "/"?) (Bob)
  • Some RPs rejected claims because they did not recognize the claim namespace generated by the IDP. (Bob)
  • Some RPs rejected claims because of case-sensitivity issues. (Bob)
  • SAML token version requirements are underspecified; IDPs and RPs need to be able to agree on the supported token versions. (Bob)
  • Base-64 encoding issues caused some failures due to incompatible assumptions about where line breaks may legally occur. (Bob)
  • Some RPs rejected claims because of ambiguities in what token information was to be included in the scope of hashes in signed tokens. (Bob)
  • Some RPs encountered issues with XML canonicalization of tokens. Use of a standard canonicalization library may be desirable. (Bob)
  • Some issues were encountered with how plaintext data was padded prior to encryption. (Bob)
  • SOAP versioning (1.1 vs. 1.2) caused compatibility issues. (Bob)
  • 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. (Bob)
  • Certificate path validation is handled in a variety of ways by RPs; some RPs experience serious performance problems due to path validation. (Bob)

Claim and token content handling

Seems to be two issues here... what is in the token, and what the RP should do with it.

  • The handling of claims with multivalued attributes appears not to be fully specified (Bob)
  • Some RPs required an exact match of required claims and presented claims; other RPs matched if required claims were a subset of presented claims. (Bob)
  • 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. (Bob)
  • 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. (Bob)
  • Some RPs rejected assertions because of issues with synchronizing clocks between IDPs and RPs. (Bob)
  • "Empty Claims" from Managed Identity Providers ‑‑ how do we get around the static nature of the 'supported claims' in a managed card? (Pam)
  1. need an enhanced claim type, this has already come up in the WS‑Federation TC in OASIS (Tony)
  • Relying Party "Faults" ‑‑ do I need to support these? ‑‑ see section 6.1 in the Identity Selector Interoperability Profile v1.0 (Pam)


Registration and selector invocation

  • 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. (Bob)
  • It was observed that some RPs are using different approaches to detecting and triggering identity selectors; this caused some failures. (Bob)
  • Some RPs exhibited different behavior on first visit (required registration of some sort) versus subsequent visits. (Bob)
  • Consistent detection of Identity Agents associated with a browser ‑‑ We need a browser‑independent convention for Identity Agents to be able to communicate presence (and preferably capabilities) to a Relying Party, *without* misrepresentation. (Pam)
  • I would say that we just need a consistent detection of an IA, as these don't have to be browser based. (Tony)
  • Consistent set of industry‑wide "supported methods" for triggering Identity Agents ‑‑ The simple "embedded object" method must be expanded on ‑‑ As a minimum, how about objects submitted via Javascript (Pam)


Platform support and installation instructions

  • Interoperability of the same code among various Linux distributions. (Eric)

Identity Provider Interop Profiles

Specify support for Token generation, claim instantiation, and encoding that matches RP scenarios, e.g. time sync can be handled by specifying bext practices for what RPs will accept.

Token contents

  • 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. (Bob)
  • 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. (Bob)

Card acquisition

  • Card creation varies from IDP to IDP, and is in many cases primitive from a human-factors point of view. (Bob)
  • Procedures for importing cards are also not standard and are in some cases complicated or confusing. (Bob)

Standard Claims

  • Support for PPID "Friendly Identifier" ‑‑ see section 8.6.3 in the Identity Selector Interoperability Profile v1.0. (Pam)
  1. I'm not sure what this covers, as it could be the generation and/or consumption, which could mean that the IA would have to support the generation of master key and also behave correctly with EV and NON EV certificates. Is this what you had in mind ? (Tony)
  2. My reading of the referenced doc indicates this is for any IdP that supports PPIDs -- personal or managed. (Dale)


Platform support and installation instructions

  • Interoperability of the same code among various Linux distributions. (Eric)


Protocol support from IA

  • X.509 and Kerberos for Authn to IdP (Tony)

Identity Agent Interop Profiles

Card acquisition

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


Platform and packaging support

  • Interoperability among platforms that do not contain "the latest and greatest". For example, CardSpace on XP or Mac software on senior‑citizen kitty‑cats.
  • Interoperability of the same code among various Linux distributions. (Eric)
  • Cooperation and interference among co‑resident software components. For instance, If I use Higgins for Firefox on a Mac and Ian Brown's Identity Selector for Safari on the same platform, will they interfere with each other? ... On the cooperation side, is there code that can be shared and only installed once in these cases? Does it work? (Eric)


User invocation

  • Non‑browser specific Selector (Tony)


Protocol support

  • Real MEX Support on Client (Tony)
  • X.509 and Kerberos for Authn to IdP (Tony)


Unresolved issues

  • Some RPs required installation of a certificate on the selector machine. (Bob)
  • Certificate path validation is handled in a variety of ways by RPs; some RPs experience serious performance problems due to path validation. (Bob)
  • 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. (Bob)
  • Using EV Certificates requires complicated configuration. (Bob)
  • 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. (Bob)
  • A help desk or help list for those of us like me who have the time and energy to participate in this interoperability testing but are having problems and need help. (Eric)
  • I would like to see me at Barcelona. (Eric)
  • WS‑Trust 1.3, WS‑Policy 1.5, WS‑SecurityPolicy 1.3, WS‑Addressing 2005, SOAP 1.2, etc. (Tony)
  • Cell Phone Based IdP (Tony)
  • Transport Bindings, +Symmetric + Asymmetric Key Bindings (Tony)
  • CardSpace compatible PPID, Friendly PPID, and SS‑Key Gen (Tony)
  • IA Compatibility but Independence from Cardspace (Tony)


Conclusion and plan modification mechanisms