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

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

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