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] RE: IBM charter position (was [security-services] Groups - sstc-saml-charter-2.0-draft-02.doc uploaded)


Hi,

Nokia fully supports comments made by RSA.

Our customers express the same urgency and need for a solution
as do RSA's customers. Besides the business related needs, 
the mobile industry is facing technical challenges introduced by legislation. 
Such issues as Privacy (avoid use of phone number as identifier) and 
number portability have created an urgent need for federated Identity solution. 
SAML 2.0 is addressing these issues whilst also providing the mobile industry
a way to bridge the mobile and fixed internet.

Regarding point 3 Nokia is also looking forward to seeing
the remaining WS-* specifications to appear in an open 
organization such as OASIS. This would allow us to also
contribute to the development of these potentially very
important specifications.


Best Regards,
Timo Skytta 
Mobile +358 40 514 2553 
Mobile email mailto:+358405142553@smsgw.nokia.com 
IM AOL/YAHOO:tskytta



>-----Original Message-----
>From: ext Philpott, Robert [mailto:rphilpott@rsasecurity.com]
>Sent: 14 November, 2003 05:21
>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_wor
>kgroup.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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]