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] | [Elist Home]

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


Thanks for your questions/response.

>> It is unfortunate that users of SAML need to go about defining a
>> via SAML attribute assertion. Furthermore, I agree that protection of
>> data in such "attribute oriented" credential assertions would need to be
>> dependent meaning that interoperability of Credentials will be
>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

"Credential specify the subject's authentication data that can be used to
the identity of the subject by a target application's security service
provider. The 
process of verifying a subject credential is part of authentication

It is possible that SAML enabled application could import their own
schema which encapsulates semantics of credentials. If the credential
is from the ds:KeyInfo, then yes we can conceivably have some level of
If, however, the credential definition is not from a well-defined namespace,
two applications using SAML will not achieve interoperability via the
credential approach suggested above unless they go through a cumbersome
process of installing these specialzied credential schema definitions.
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
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.
>> also claim that such procesing of security extensions in application
>> which is correct design goal for SOAP messaging systems, IMO.
>> protocols was an area that ws-security has prudently not included in
>> 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
specification and their latest schema (dated 1/17/02):



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
   other security extensions, as part of SOAP messages. SAML 1.0 does not
   have the explicit capability to attach credential in SOAP envelopes. I
   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
   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. 


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

Powered by eList eXpress LLC