FW: [security-services] Comments onsstc-saml2-attribute-management-protocol-01

Posting on behalf 
of Phil who is an observer.

Begin forwarded message:

  

  
From: Phil Hunt <>

  
Date: March 3, 2010 10:25:37 AM 
  PST (CA)

  
To: Scott Cantor <>

  
Cc: "'Nguyenphu, Thinh \(NSN - 
  US/Irving\)'" <>, "'OASIS 
  SSTC'" <>

  
Subject: Re: [security-services] 
  Comments on sstc-saml2-attribute-management-protocol-01

  

  
There 
  were a couple of changes we were suggesting in terms of "operations". One was 
  the ability to manipulate subjects and not just attributes.  And the 
  other was to allow for delete and replace operation on attributes.
  

  

  
1. Entity Management.  The requestor should be able to request 
  life-cycle control over an entire entity

  

  
<element 
  name="ManageSubjectRequest" type="samlp:ManageSubjectRequestType" 
  />  

  
    
  <complexType name="ManageSubjectRequestType">

  
     
     <complexContent>

  
    
    <extension base="samlp:RequestAbstractType">

  
     
  <sequence>    

  
    
    <choice>

  
    
  <element name="AddSubject" 
  type="samlp:AddSubjectType"/>

  
    
  <element name="ModifySubject" 
  type="samlp:ModifySubjectType"/>

  
    
    </choice>

  
     
  </sequence>

  
    
    </extension>

  
    
    </complexContent>

  
    
  </complexType> 

  
You will notice that there is no "DeleteSubjectType". Reading the original 
  2.0 spec, the delete could be handled by ManageNameIDRequest - Terminate. 
  I'm not sure this  is the current intended use. Would it be appropriate 
  to modify the use for this purpose here?

  
2. Managing attributes would be part of the "ModifySubject" operation.

  

  
<complexType name="ChangeValueType">

  
  <sequence>

  
  <choice>

  
  <element ref="saml:Attribute"/>

  
  <element ref="saml:EncryptedAttribute"/>

  
  </choice>

  
  </sequence>

  
</complexType> 

  
<complexType name="ModifySubjectType">

  
  <sequence>

  
  <choice>

  
   <element ref="saml:NameID"/>

  
  <element ref="saml:EncryptedID"/>

  
  </choice>

  
  <sequence>

  
  <choice>

  
  <element name="AddAttributeValue" 
  type="samlp:ChangeValueType"/>

  
  <element name="DeleteAttributeValue" 
  type="samlp:ChangeValueType"/>

  
  <element name="ReplaceAttributeValue" 
  type="samlp:ChangeValueType"/>

  
  </choice>

  
  </sequence>

  
  </sequence>
</complexType>
  

  
The big change here is that in addition to simply adding an attribute, 
  requestors can request delete or replace operations.

  
I also agree, there are things to be sorted out such as namespace and 
  signing (what is signed and who is signing). IMHO at minimum the requesting 
  service needs to sign the transaction somehow. In the ideal world, a token 
  representing the requesting end-user would also make sense though it may not 
  be needed in all cases.  The requirements for signing would have to be 
  dictated by the site receiving the modify request (e.g. IDP).

  
Finally, one other item that will need to be solved.  In the use cases 
  described, it is quite reasonable that the requestor may only be able to make 
  these operations as "suggestions" and that the IDP receiving the operation is 
  not obligated to process them or interpret them exactly as specified. The key 
  requirement as I see it, is to have enough semantics in the SAML request to 
  make it clear to the IDP what the requesting service provider is asking for. 
  More request "context" for the IDP means more data to base a decision 
  on. 

  
There will also be other metadata requirements such as governance, privacy, 
  and assurance that may have to fit within these requests.

  
Finally, I have a feeling, there is some information we can learn from 
  SPML2 as applied to messaging that may be of use in these 
  discussions.

  

  

  

  

  

  

  

  
Phil

  


  

  
On 3-Mar-10, at 7:31 AM, Scott Cantor wrote:

  
    

    Document

    needs XML namespace assigned, it's not in this 
      draft. Suggest

    urn:oasis:names:tc:SAML:2.0:profiles:attribute-management

    

    [Thinh] My understanding based on our proposal, we 
      do need to define a

    new namespace.  Because, we just extend the 
      existing SAML protocol

    schema.

If you meant to say "we 
    do not need...", that would be incorrect. We can't
add to the original 
    namespace if that's what you're suggesting. Doing that
would mean 
    revising the entire SAML standard and publishing a 2.1, because
the 
    original schema artifact is part of the old publication set.

    [Thinh} When using AttributeStatements, we see the 
      advantage that an

    AttributeStatement can be signed by one issuer, in 
      contrary to an

    Attribute.

Statements can't be 
    signed, only assertions. There's no mention of using
assertions here, and 
    the message can be signed anyway.

    If a SP sends a signed AttributeStatement to an 
      IdP, then the

    IdP is enabled to know who is the issuer of this 
      AttributeStatement. Can

    you elaborate on the reasons for your 
      preference?

I don't really like injecting the complexity 
    of assertions into this unless
there's a good reason.

-- 
    Scott

---------------------------------------------------------------------
To 
    unsubscribe from this mail list, you must leave the OASIS TC 
    that
generates this mail.  Follow this link to all your TCs in OASIS 
    at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php