[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Groups - sstc-saml-charter-2.0-draft-02.doc uploaded
I would agree with the merits of componentization and the power of mix-and-match capabilities. However, as an end consumer our interest is ultimately interoperable products. We believe the ability for us to improve the means by which we do business with our customers, partners, and suppliers can be accomplished through ease of use and reduction in administration. We see this accomplished by delivering interoperable SSO and identity federation. So although technology design principles suggest separation of these standards as a good thing, it would not seem to lead to an interoperable solution for our business needs. I think the flexibility you have proposed will allow the vendors to 1) pick and choose the standards to be implemented in their products thus confounding interoperability, or 2) force the vendors to implement all combinations of the specifications/standards which adds complexity to our deployments and burns vendor resources (which we as a customer ultimately pay for). Therefore Boeing is in favor of the single package concept that facilitates company to company business collaboration. Having many ways to assemble the pieces sounds too much like what we have today. Mike Beach -----Original Message----- From: Anthony Nadalin [mailto:drsecure@us.ibm.com] Sent: Tuesday, November 11, 2003 8:45 AM To: 'security-services@lists.oasis-open.org ' Subject: [security-services] Groups - sstc-saml-charter-2.0-draft-02.doc uploaded IBM would like to clearly articulate its concerns to the recent proposed charter changes to include identity federation: IBM believes that efforts focused on the standardization of general mechanisms for Web based authentication and authorization activities should continued to be done in the SS-TC and activities focused on identity federation should be done in another TC. This would be analogous to the SST-TC and the XACML TC division of duties. Today there are a proliferation of security technologies in use and these will continue to be in use, and the identity federation technology must be able to deal with these diverse and disparate technologies while being able to compose with existing applications. It is not in the best interests of the SS-TC or the market to force vendors to either support identity federation, or some specific version of identity federation, or not support SAML at all. Furthermore, combining SAML with identity federation may further fragment the market by creating the need for an alternative SAML assertion framework in regards to identity federation. We feel that the identity federation work is more cleanly handled in a separate TC. There are strong technical reasons why IBM feels that a more modular and functionally cohesive approach would be better than merging authentication/authorization and identity federation technologies in the existing SS-TC. We agree with the statement made at a recent TC meeting that "It is better to have more simple things than fewer complex things". As SS-TC attempts to expand to deal with its broader scope, it is becoming less capable of performing its previous commitments. Previously well engineered elements and attributes are being "generalized" with special purpose attributes.. The semantics of these increasingly complex structures and functions are becoming increasingly unclear. IBM believes that it would be better to separate the specifications, not just the documents but technology interdependencies, for different assertion types and protocols. The assertions and protocols could be layered on a common base and build up from there. This would not only reduce complexity but would allow subject matter experts to more effectively participate in the specification process. People unfamiliar with internal TC activities would be surprised to learn that a group chartered to work on authentication and authorization is working on identity federation. Even the current issues list for SAML 2.0 acknowledges that ""identity provider” is broader than “authentication authority””. Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]