Next in thread → Next in month →

RE: [security-services] suggested text for AI-32 re: non-use of confirmation data in BAP and a couple of editorial changes

From
Jahan Moreh <>
Date
2003-04-29T23:48:09+00:00
ID
Thread
RE: [security-services] suggested text for AI-32 re: non-use of confirmation data in BAP and a couple of editorial changes
A minor 
correction.

 

All references to urn:oasis:names:tc:SAML:1.0:cm:artifact-01 
should be replaced with 

urn:oasis:names:tc:SAML:1.0:cm:artifact

 

Thanks,

Jahan

 

----------------
Jahan Moreh
Chief Security 
Architect
310.286.3070 

  
-----Original Message-----
From: Philpott, Robert 
  [mailto:]
Sent: Tuesday, April 29, 2003 
  4:45 PM
To: 
  ''
Subject: 
  [security-services] suggested text for AI-32 re: non-use of confirmation data 
  in BAP and a couple of editorial changes

  

  
The following changes are for the 
  Bindings and Profiles Document.  Line references are relative to the 
  draft-02 Word document.

  
 

  
Line 499 uses the term 
  "authentication assertion".  This is an error and should actually be "SSO 
  assertion".

  
 

  
In response to my action item, the 
  text at lines 523-526 is currently:

  
 

  
523  At least one of the SAML assertions returned 
  to the destination site MUST be an SSO 
  assertion.

  
524  Authentication statements MAY be distributed 
  across more than one returned assertion.

  
525  The <saml:ConfirmationMethod> element of each assertion MUST be set 
  to  

  
526  urn:oasis:names:tc:SAML:1.0:cm:artifact-01.

  
 

  
Note that this text is not very 
  precise since a confirmation is not really associated with an entire 
  assertion.  It is part of the SAML subject that appears in every 
  statement within an assertion. I am assuming that the CM should be in every 
  statement in the SSO assertion.

  
 

  
Also, I understand that we allow 
  requests that include multiple artifacts, so I can understand how multiple SSO 
  assertions would need to be returned.  However, I do not understand a use 
  case that would result in any assertions **other than SSO assertions** to be 
  returned in the samlp:Response to a samlp:Request for AssertionArtifact. Such 
  a response seems to be permitted by line 523, but I don't quite "get 
  it".  

  
 

  
However, since other folks might 
  get it, I am not recommending a change to the first 2 lines above. 
  

  
 

  
I do recommend an editorial 
  clarification for the last 2 lines (525-526) and some additional text to 
  satisfy the action item I took as follow:

  
 

  
The <saml:Subject> element for each statement in the SSO 
  assertion(s) being returned MUST contain a <saml:SubjectConfirmation> element as defined 
  below:

  
    
The <saml:ConfirmationMethod> element MUST be set to  
    urn:oasis:names:tc:SAML:1.0:cm:artifact-01 

    
The <SubjectConfirmationData> element 
    SHOULD NOT be specified. 

  
 

  
Note that I expressly limited the 
  inclusion of the SubjectConfirmation to the SSO assertions since I didn't 
  understand a use case for other assertions being included.

  
 

  
I think this is okay for V1.1, but 
  we should clarify it a bit more in V2.0.

  
 

  
Anyone disagree with these 
  changes?

  
 

  
Rob 
  Philpott 
  
RSA 
  Security Inc. 
  
The Most 
  Trusted Name in e-Security 
Tel: 
  781-515-7115 
Mobile: 
  617-510-0893 
Fax: 
  781-515-7020 
mailto:
Next in thread → Next in month →