RE: [security-services] SOAP Profile of SAML vs WS-Security: Summaryand an Action Plan

[Krishna Sankar <ksankar@cisco.com>]

Zahid,

	Good three point summary ! Agree with them all.

	Re WS-Confidentiality and WS-Integrity, I do not think MS has added
anything. Just two more elements and a very generic syntax. IMHO, both are
superfluous (for now) unless there are some new syntax and semantics around
them, which ds:Signature and EncryptedData elements from their respective
specifications couldn't capture. In this respect, I am agreeing with Hal.

	BTW, can anybody tell me what *real* function does the WS-Confidentiality
and WS-Integrity elements serve in the WS-Security specs ? How would these
two elements make any difference ? Consolidating multiple-signatures ?
Distributing encrypted data at different places in a packet ?

	Re Ws-Credential, SAML needs a Credential Assertion which is what
WS-Credential has defined. (while we are on this subject, SAML needs the
Session Assertion as well, which I hope we will tackle soon after 1.0 is
released)

	I really do not think we would get anything from the WS-XXXX specifications
(as they stand now) for the SOAP binding. But, as Zahid points out, with a
*first class* credential assertion and some more maturity from the WS-XXXX
specifications, hopefully, we would have a better SOAP binding in the next
rev.

cheers & have a nice weekend

 | -----Original Message-----
 | From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]
 | Sent: Friday, February 15, 2002 1:05 PM
 | To: 'Hal Lockhart'; security-services@lists.oasis-open.org
 | Subject: RE: [security-services] SOAP Profile of SAML vs WS-Security:
 | Summ ary and an Action Plan
 |
 |
 | Hal,
 |
 | Thanks for your questions/response.
 |
 | >> It is unfortunate that users of SAML need to go about defining a
 | Credential
 | >> via SAML attribute assertion. Furthermore, I agree that protection of
 | verification
 | >> data in such "attribute oriented" credential assertions would
 | need to be
 | application
 | >> dependent meaning that interoperability of Credentials will be
 | questionable.
 | ....
 | >I don't under your viewpoint. SAML has defined the semantics of
 | attributes
 | and a method of
 | >including any schema. It has defined some simple cases and a method for
 | profiling new usages.
 | >Since what you seem to want to do is use a ds:KeyInfo in an Attribute
 | Assertion, there does
 | >not seem to be anything left to define. You can use this today
 | and anyone
 | can interoperate.
 |
 | I believe we have discussed the definition of credentials in
 | this TC before.
 | For the
 | purpose of this discussion, if we re-use a variant of those set of
 | definitions:
 |
 | "Credential specify the subject's authentication data that can be used to
 | verify
 | the identity of the subject by a target application's security service
 | provider. The
 | process of verifying a subject credential is part of authentication
 | process."
 |
 | It is possible that SAML enabled application could import their own
 | "attribute"
 | schema which encapsulates semantics of credentials. If the credential
 | specification
 | is from the ds:KeyInfo, then yes we can conceivably have some level of
 | interoperation.
 | If, however, the credential definition is not from a
 | well-defined namespace,
 | then
 | two applications using SAML will not achieve interoperability via the
 | "assertion-orienetd"
 | credential approach suggested above unless they go through a cumbersome
 | process of installing these specialzied credential schema definitions.
 | Proliferation
 | of multiple definitions of credential schema is not going to work.
 |
 | Hence, it would be useful to define a set of concrete
 | definitions of useful
 | Credentials that should be part of the SAML Content Model, i.e.,
 | Assertion
 | specification.
 | Using attribute assertion to model credential I  believe is only a
 | workaround to the
 | current limitation in SAML 1.0 of not being able to employ well-known
 | "authentication data" elements from standard namespaces.
 |
 |
 | >> I agree that Microsoft's GXA does not address the semantic processing
 | >> requirements of Credentials. But in some ways thay have taken
 | the first
 | step in
 | >> specifying a flexible model of associating Credentials in
 | SOAP messages.
 | They
 | >> also claim that such procesing of security extensions in application
 | dependent
 | >> which is correct design goal for SOAP messaging systems, IMO.
 | Authentication
 | >> protocols was an area that ws-security has prudently not included in
 | their
 | >> specs via their design goal of application level security.
 | ....
 | >I disagree completely. I am looking at the WS-Security and WS-License
 | specifications. Are
 | >you perhaps refering to some other specifications? They do not
 | define any
 | semantics. As
 | >far as syntax, they basically define an empty bucket in which
 | one can put
 | an ill spefified
 | >object. For example, take Kerberos ticket. What kind of ticket? Only a
 | service ticket addressed
 | >to the relying party is of any use. Can it be cross realm? Does
 | it include
 | an Authenticator?
 | >Microsoft frequently encrypts with RC5, instead of DES. How do
 | I know what
 | the ticket
 | >is encrypted with? In my view, MS-License and MS-Security provide an
 | incompeltely specified
 | >format for sending unknown objects for unknown purposes. I
 | assert that SAML
 | has done far
 | >more than that, and if we had the help of interested parties, we could
 | conmplete this process
 | >in a week or so.
 |
 | I think we are more in agreement here w.r.t. status of Microsoft's GXA
 | ws-security
 | specification and their latest schema (dated 1/17/02):
 |
 | http://msdn.microsoft.com/ws/2002/01/Security/
 |
 | http://schemas.xmlsoap.org/ws/2002/01/secext
 |
 |
 | Difference between ws-security and SAML 1.0 and some limitations:
 |
 | 1. Inclusion of Credential (Authentication data) in SOAP Message
 |    ws-security includes an approach of including credentials, among
 | additional
 |    other security extensions, as part of SOAP messages. SAML 1.0 does not
 |    have the explicit capability to attach credential in SOAP envelopes. I
 | believe
 |    that is one of these reasons why we had to delay the release of SOAP
 |    Binding of  SAML.
 |
 | 2. Schema Definition of Common Credentials and
 |    ws-security includes some commonly used schema definitions of
 |    some commonly used Credentials and also a way to import other
 |     credentials from foerign namespaces. SAML content model lacks
 |     definition of such elements currently although in some cases
 | attributes
 |     could be overloaded with credential semantics.It is true that the
 |     abstract definition of Credential currently lacks an
 | authenticator.
 |
 | 3. Credential Authentication Model
 |    ws-security also lacks any discussions of authentication
 | process, i.e.,
 |    credential data validation. However, that is consistent with
 | design goals
 | of
 |    ws-security w.r.t. its focus on application security. So, we
 | agree that
 |    semantic processing of credentials (i.e, authentication data) is not
 |    included in ws-security nor is it included in SAML 1.0. This is
 |    possibly an area that could be fixed in both ws-security and SAML
 |    in the future.
 |
 |
 | thanks,
 | Zahid
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 | ----------------------------------------------------------------
 | To subscribe or unsubscribe from this elist use the subscription
 | manager: <http://lists.oasis-open.org/ob/adm.pl>
 |