[security-conform] FW: Feedback on the SAML conformance documents,from Sal Allavarp u

hi Sal 
-

 

thanks 
for the comments!  i'm figuring to have a call in the week after 
Thanksgiving, and would be interested to discuss them in more detail 
then.

 

regards,

 

bob

 

-----Original Message-----
From: Sai Allavarpu 
[mailto:]
Sent: Tuesday, November 13, 2001 6:21 
PM
To: ; ; 

Subject: Fw: Feedback on the SAML conformance 
documents

I am not authorized to send an email 
to security-conform alias. Can you forward this on my behalf to the 
sub-committee members?

 

Thanks,

Sai.

----- Original Message ----- 

From: Sai 
Allavarpu 

To:  
; Sai 
Allavarpu 

Cc: Aravind Ranganathan 

Sent: Tuesday, November 13, 2001 3:14 PM

Subject: Feedback on the SAML conformance documents

I have to appreciate the SAML 
conformance documents and the dual approach taken toward them. The approach 
where the conformance is determined by a questionnaire is more useful to 
both the vendors and the market to understand what it means to claim SAML 
conformance at various levels.

 

After having discussed this in the 
market and with customers, I have some feedback to share on the SAML compliance 
doc.

 

First, the market is clearly excited 
about the SAML standard, especially the standardized schemas (data formats) for 
all the 3 global types of assertions and the standardized request/response 
formats/schemas. The major refrain from the market is that they want to ensure 
SAML is widely adopted by different vendors and the industry. Toward this 
ultimate goal of wide adoption, they want to ensure that SAML conformance specs 
are not only simple and specific but also reflective of the existing market 
deployments. SAML should not be a "discontinuous" or a "disruptive" change to 
deployments; SAML should help past and current deployments get to the future 
desired deployments of web services and SOAP.

  
The conformance model should be 
  based on (A) multiple dimensions and (B) multiple levels of conformance within 
  each dimension. The idea of a supplier and a consumer is one dimension. But 
  other dimensions that the market cares about are (in the increasing order of 
  conformance) 
  
    
conforming to the data 
    format/schema of assertions (authentication/authorization/attribute) 
    
conforming to the data 
    format/schema of the SAML request/response 
    (authentication/authorization/attribute) 
    
conforming to the SAML bindings 
    (SOAP, HTTP, Socket, etc)

  
Within each of the above dimensions, 
  there can be levels of compliance. For instance, some one who wants to be the 
  Authentication authority but not the attribute authority should be able to 
  claim conformance to the AA assertions and request/response schemas. 
  
By mandating one 
  baseline binding, are we implying that all users of SAML will have to support 
  it in addition to any other bindings they care about, or is it only a matter 
  of picking a single binding to work on in the V1.0 timeframe?  What will 
  be the timeframe/mechanism for documenting other bindings, even if they're not 
  "blessed" by the TC yet?  Our original plan  was to eventually offer 
  multiple bindings; using SAML across domains should be a matter of picking a 
  common (and standardized) binding. Conformance in this area should be a "set 
  of binding protocols" to choose from and let the parties in SAML transactions 
  negotiate the binding by picking one from the "set of binding 
  protocols". This should be 
  something similar to the cipher negotiations that happen in SSL connections, 
  for example. 
  
The market is gung-ho 
  about SOAP and web services but do NOT want to deploy them right away because 
  they perceive SOAP as a "discontinuous change" or a "disruptive technology" 
  despite the base HTTP layer over which most SOAP implementations are 
  implemented. So if HTTP binding is not one of the "set of binding protocols", 
  then SAML will hurting its chances of quickly and widely being adopted by the 
  market, and will be left out of tons of markets. Customers are concerned about 
  deploying SOAP because of immaturity of its firewall technology and SOAP, 
  inadequate skilled system administrators to configure and manage SOAP traffic, 
  relatively new support in the leading application servers, SOAP 
  standardization and evolution, etc. 
  
SAML in non-web 
  scenarios is also severely hampered because of lack of bindings such as Socket 
  bindings, for example. For example, what about using SAML in 
  Netware/Lotus Notes SSO? How to bridge the existing non-web applications with 
  web apps and SAML? 
  
If we had to pick the next few bindings 
  that should be worked on, they should be HTTP and sockets.  If the HTTP 
  binding is nearly there, we should publish it as a draft anyway, so people can 
  get started with it. This will get the industry on SAML lot quicker, 
  easier and sooner. A socket binding would be even simpler, since it 
  doesn't have to worry about SAML information that would go into a 
  header.
Sai.