RE: [security-services] draft-sstc-meta-data-00.doc

Rob,

 

I am starting 
a thread with your message as some of your suggestions have 
pretty

broad scope 
and we need to wrestle with them a little before we are ready to 

make changes 
to the meta data document.

  

 

  
To summarize my key 
  points:

  

  
    
I recommend 
    sticking to "Asserting Party" and "Relying Party" terminology rather than 
    "Source Site" and "Destination Site", etc. 
 
[Prateek Mishra]  While the terms 
    "Asserting/Relying Party" are more standard in the literature, we have used 
    the terms "Source Site" and "Destination Site" consistently in the Bindings 
    and Profiles document. So I would prefer to stay with these 
    terms.

  
 

  
    
I also recommend 
    using names for the various services that are used in the main specs (e.g. 
    "Artifact Receiver Service", "SAML SOAP Binding Service") 
    
[Prateek 
    Mishra] Fair enough, I will make an editing pass to ensure that we 
    haven't missed any such terms. I will review your marked-up doc to see 
    if there are some that have been mis-labeled. Note that there appears 
    to be a misunderstanding regarding the 
    term:

SAMLProtocolBindingID

This refers to the "type" of 
    binding used to retrieve assertions from artifacts. Notice that the artifact 
    profiles do not requre use of the SOAP binding. This is where the specific 
    binding URI (e.g., SOAP binding URI) is indicated. 

  
 

  
    
I think there's 
    still quite a bit of metadata missing... For example: 
    
      
Type of artifact 
      being used (Type 1 or Type 2) 
[Prateek 
      Mishra] Type 2 artifacts are not normative and purely informational. 
      I had not planned to cover them in this document. Should 
      we? 
      
Supported SAML 
      Authentication Methods 
[Prateek 
      Mishra] This one I could not follow. Section 2.1.1.1.1 TrustModelType 
      describes different ways source and destination site authenticate to each 
      other. Could you please explain what was meant here?

      
DSig requirements 
      - Whether to sign requests, responses, and/or assertions; the C14N 
      algorithm being used, etc. 
[Prateek 
      Mishra] There is exactly one place in the web browser profile where 
      signing is required. This is the POST profile wherein the 
      response object must be signed. Rules for signing are (e.g. 
      C14N algorithm etc.) are called out in Section 5 of the core 
      specification. In addition, Section 2.1.2 FORMPostMetadata describes 
      the certificate/public-key that would be used to validate the signature. 
      

    
        What other 
    information is required here? 

    
      
Agreed-upon 
      Subject Name Qualifiers being used between the partners 
      
[Prateek 
      Mishra] Agreed. I assume you mean the identification of the exact 
      Name Qualifier to be used within the 
      <NameIdentifier> 

      
Agreed-upon 
      Attribute NameSpaces being used between the partners. 
      
[Prateek 
      Mishra] Agreed. Should we not identify BOTH the attribute 
      name and namespaces that might be found in the assertion. One or more 
      occurrences of the element <AttributeDesignator> can hold this 
      information.
      
Names of 
      supplemental schemas required for document validation (e.g. for when 
      external schemas are used to describe complex attribute 
      values). 
[Prateek Mishra] I am not totally sure this fits in 
      here. Each attribute name carries a namespace indicator. Given the 
      two, the receiving party can figure out which schema to use for validating 
      document values etc. I guess I need to understand this somewhat 
      better.

      
Web SSO Assertion 
      contents (just Authn Statements? Attribute Statements?) 
      
[Prateek 
      Mishra] Can this be represented as: (1) just an authn statement 
      
(2) authn statement and attribute statements ? Is that 
      adequate?
 
      
What SubjectLocality info is 
      provided.
[Prateek Mishra]  I assume you mean (1) WHETHER the 
      optional <SubjectLocality> element is present (2) what are its 
      contents ?  I guess we could model this by an instance 
      of a <SubjectLocality> element.
      
Etc. 
    

  
 

  
Thanks for the comments. Resolving them will take the meta-data 
  doc forward quite a bit.

  
 

  
- prateek