RE: RSA SAML Interop technical issues

Title: RSA SAML Interop technical issues

Hi,

Due to the overwhelming response to the issues in this 
email (re:  none), I have updated the Guidelines with the suggested 
settings and they are attached.  Thanks to all those vendors who sent their 
updated metadata.

See you in SF,

Bob

From: Ciochon, Robert 
Sent: 
Wednesday, February 09, 2005 4:30 PM
To: 
samldemotech
Subject: RSA SAML Interop technical 
issues

Hi, 
During the dry 
run we were able to assemble the metadata for all vendors who are 
participating.   If you have had to change your metadata since the dry 
run, please send it out to the list so everyone can maintain a current version 
for their providers.  This will be one less step that will need to be done 
at show setup.  Note that some vendors were running without SSL at the dry 
run.  If you were one of them, SSL will be required for the show and your 
metadata will need to change.

A few items came up during the dry run that were 
accomodated, but in the interest of a smoother show setup everyone wanted 
standardized.  Please respond if you disagree with the proposed 
requirements for the SAML Interop:

  
RelayState in an idP initiated SSO - This varied 
  between vendors, with some passing a valid URL, others sending an empty 
  string, others not sending it at all and still others using a special 
  string.  The concensus of those on the conference call today was to 
  specify that the RelayState is optional, but if sent, it MUST be a valid 
  URL. 
  
XML signature KeyInfo element - Some vendors were 
  failing if an XML sig was sent without having the key embedded in the KeyInfo 
  element.   The concensus on the call was to have it optional if the 
  KeyInfo is sent and not have it required by any vendor. 
  
Signing AuthnRequest - The Metadata standard 
  provides for separate settings for idP and SP on whether an AuthnRequest 
  should be signed, and they can conflict (the SP metadata specifying don't sign 
  it, the idP specifying it must be signed).  The concensus on the call was 
  to leave it up to the SP to specify if the AuthnRequest was signed, and the 
  idP would not have a preference.  However, it appears from the spec this 
  can't be set for the idP (it requires either always or never signed), so 
  instead, the requirement is that all AuthnRequests will be signed. 
  

Please respond as soon as possible to the above 
issues, as a decision will be put in writing on Friday. 
Regards, 
Bob 

Robert Ciochon 
eTrust Development Manager 
Computer 
Associates 
San Diego, California 

(858) 625-6866 
 

RSA2005-saml-interop.doc