Re: [wss-comment] 2 comments on WSS 1.0 spec now balloting at OASIS

[Anthony Nadalin <drsecure@us.ibm.com>]

There were issues with SAML 1.0 and a proper identifier, these seem to have been corrected in SAML 1.1, so some of this was a timing issue and a desire to get the most popular tokens types (at the time) out first. As others have indicated work to get a proper interop and profile agreed upon is in progress, along with profiles like XrML and Kerberos.

IBM and Microsoft have demonstrated the usage of the SAML Token Profile (and other Token Profiles) in WS-Federation demos and interop events, so not all commercial web services security products are out creating thier own SAML-SOAP binding. Have you taken this issue to the Security Services (SS-TC) TC in OASIS as they are in the midst of SAML 2.0 set of specifications and now would be the time to make sure that things become aligned?

Anthony Nadalin | work 512.838.0085 | cell 512.289.4122
Michael.Mccormick@wellsfargo.com

Michael.Mccormick@wellsfargo.com

03/17/2004 09:09 AM

To	wss-comment@lists.oasis-open.org
cc
Subject	[wss-comment] 2 comments on WSS 1.0 spec now balloting at OASIS

Comment #1
Document: Web Services Security: SOAP Message Security (WS-Security)
Comment: Although general guidance is provided regarding XML security
tokens, WSS 1.0 does not include a security assertion markup language (SAML)
assertion/token profile.  This is a serious omission given the critical role
of SAML in so many federated identity solutions now being deployed.  The
omission has forced a number of commercial web services security products to
create their own SAML-SOAP bindings (or use the one promoted by the Liberty
Alliance) in order to meet customer demand.
Recommendation: Include a SAML 1.1 profile in the next WSS version as early
as possible.

Comment #2
Document: Web Services Security: Username Token Profile
Comment: The UserName Token element (/wsse:UsernameToken) does not provide
any means of qualifying the user name to indicate its type or domain.
Optional sub-elements should be defined for type (with several types
pre-defined including e-mail address and Microsoft SAM account name) and
domain (DNS or NT/AD).  Without such qualifiers a <Username> value can often
be ambiguous or non-unique.  For an example of XML type and domain
qualifiers, refer to the Username schema in the security assertion markup
language (SAML).
Recommendation: Add optional qualifiers to UsernameToken in the next WSS
version.

Michael McCormick
System Architect
Wells Fargo Services Company
255 Second Ave. South
MAC N9301-027
Minneapolis MN 55479
> *  612-667-9227 (voice)
> *  612-590-1437 (cell)
* 612-621-1318 (pager)
> *   612-667-7642 (fax)
> *  mailto://michael.mccormick@wellsfargo.com
> *  m.mccormick@acm.org
"THESE OPINIONS ARE STRICTLY MY OWN AND NOT NECESSARILY THOSE OF WELLS
FARGO"


To unsubscribe from this list, send a post to wss-comment-unsubscribe@lists.oasis-open.org, or visit http://www.oasis-open.org/mlmanage/.