Next in thread → Next in month →

RE: [security-services] X509 Authn-based Attr Sharing Profile Comments

From
Thomas Wisniewski <>
Date
2005-02-25T18:49:32+00:00
ID
Thread
RE: [security-services] X509 Authn-based Attr Sharing Profile Comments
Title: X509 Authn-based Attr Sharing Profile Comments

Rick, 
hi. One other comment. 

 

I'm 
not clear on the SubjectConfirmationData requirements. Specifically the use of 
bearer. Can you elaborate on when that would be used instead of holder-of-key in 
this profile?

 

Thanks, Tom.

  
-----Original Message-----
From: Thomas Wisniewski 
  [mailto:]
Sent: Thursday, February 24, 
  2005 5:20 PM
To: 
Cc: 
  
Subject: [security-services] 
  X509 Authn-based Attr Sharing Profile Comments

  
Rick, here are some comments on the 
  X509 profile. 
1.(section 
  1.4.1.1) It seems appropriate that the IDP should decide what attributes are 
  shareable and return them in a attribute query response.. Asking for the 
  specific set each time is bound to impact performance and since we are 
  authenticating the sender, it should not pose a security issue. The IDP should 
  have a policy as to what is shareable with any given SP and provide them 
  accordingly. I would propose to remove this section from the doc. Note if the 
  AttributeQuery has an option of AttributeConsumingIndex similar to the 
  AuthnRequest, that may have been used instead. However to specify all the 
  attributes requested each time seems like it is unnecessary if a policy allows 
  it.

  
2. The document does not discuss 
  whether Attributes should be encrypted or not. Since the Assertion MUST be 
  encrypted, perhaps it should say that Attributes SHOULD NOT or MUST NOT be 
  encrypted.

  
3. Regarding digital signatures 
  (sections 1.3.1.3 and 1.3.2.2). SAML in general usually allows for other ways 
  to authenticate, etc... msgs when using a back channel binding (e.g., soap). 
  Why can't this be used as well in this profile vs. having to use dig 
  signatures. I assume that signing just the Assertion is not an alternative 
  either?

  
4. you have the dig sig and 
  encryption sections in different order in sections 1.3.1 and 1.3.2 (was that 
  on purpose)? 

  
Tom.
Next in thread → Next in month →