OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]