RE: [security-services] RE: IBM charter position (was [security-services] Groups - sstc-saml-charter-2.0-draft-02.doc uploaded)

["Beach, Michael C" <michael.c.beach@boeing.com>]

I think it would be excellent if these "other customers" would come to the table with their needs.  As it is, I agree with Rob that we need a solution to our business problem sooner rather than later.

Mike

-----Original Message-----
From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
Sent: Thursday, November 13, 2003 7:21 PM
To: 'Anthony Nadalin'; 'security-services@lists.oasis-open.org'
Cc: Whitlock, Stephen
Subject: [security-services] RE: IBM charter position (was
[security-services] Groups - sstc-saml-charter-2.0-draft-02.doc
uploaded)


Tony - I'd like to make several points re: IBM's position...

1. Why would one jump to a conclusion that incorporating functionality into
SAML to support certain aspects of identity federation constitutes a
"monolithic approach"?  Whatever approach we take to include this
functionality should certainly be done with modularity and evolvability in
mind. 

2. The SSTC has been successful to date because it has focused on clearly
defined use cases that are important to customers and because we could make
the right tradeoffs on functionality vs time-to-standardization. RSA
Security has real customers that want the identity federation enhancements
that are being proposed.  It's clear that other SAML vendors are seeing this
same need from their customers.  These customers want these capabilities
sooner rather than later.  Do you really feel that this TC should ignore the
needs of its constituents while we wait for some promised generalized
approach to federation to be taken up in a newly formed TC (assuming it is
done in OASIS) that then develops use cases and requirements, evaluates
proposed solutions, ..., and eventually standardizes a solution? After
that's done, customers using SAML solutions still won't have something that
works with SAML.  The SSTC still would have to go back and modify SAML to
take advantage of whatever that solution provides. Our customers will not
tolerate us waiting for this approach.

3. Many folks believe that the industry will benefit from the evolution of
the WS-* specifications under the auspices of standards bodies such as
OASIS.  Should an OASIS TC be formed to address broader federation issues
for WS, I believe that SSTC members would applaud that and you'd see a fair
amount of crossover between the TC's as their has been with WSS, XACML, etc.
It would be natural for SSTC to liaise with that effort and then consider
future changes to SAML to integrate where necessary and appropriate. 


Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com 


> -----Original Message-----
> From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
> Sent: Thursday, November 13, 2003 7:15 PM
> To: security-services@lists.oasis-open.org
> Cc: Whitlock, Stephen
> Subject: RE: [security-services] Groups - sstc-saml-charter-2.0-draft-
> 02.doc uploaded
> 
> 
> 
> 
> 
> Mike,
> 
> I understand your view  but my point is that the monolithic approach has
> in
> the past has proven this is very problematic  (also Jamie Lewis of Burton
> Group gave a very good talk about composibility at the Catalyst conference
> around the WS-* specifications). Also SAML is not a choice for all end
> consumers, thus the end customer gets into a take it or leave it situation
> (which is not good for a standard).  The current approach  in the SS-TC
> seems to work well for Boeing but there are other customers where this is
> not a choice and going down the route of a componentization model solves
> both set of requirements and a broader sets of customers.
> 
> I hope this helps further explain my posting.
> 
> 
> Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
> 
> 
> |---------+---------------------------->
> |         |           "Beach, Michael  |
> |         |           C"               |
> |         |           <michael.c.beach@|
> |         |           BOEING.COM>      |
> |         |                            |
> |         |           11/13/2003 04:05 |
> |         |           PM               |
> |---------+---------------------------->
>   >-----------------------------------------------------------------------
> -------------------------------------------------------------------------|
>   |
> |
>   |       To:       Anthony Nadalin/Austin/IBM@IBMUS, <security-
> services@lists.oasis-open.org>
> |
>   |       cc:       "Whitlock, Stephen" <stephen.whitlock@BOEING.COM>
> |
>   |       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
> 
> Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to http://www.oasis-
> open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.