OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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:

  1. 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.
  1. 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:


    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.
  1. I think there's still quite a bit of metadata missing... For example:
    1. 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? 
    2. Supported SAML Authentication Methods
      [Prateek Mishra] This one I could not follow. Section TrustModelType describes different ways source and destination site authenticate to each other. Could you please explain what was meant here?
    3. 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? 
    1. 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> 
    2. 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.
    3. 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.
    4. 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?
    5. 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.
    6. Etc.


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


- prateek


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC