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: [security-services] metadata and an ISSUE for 1.1 re: use of "source"and "destinatio n"

I think it's useful to break out the discussion on this point to its own thread...


  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.



I feel that the use of the terms "source" and "destination" are too ambiguous to be used in our documents and believe they should be changed to "asserting party" and "relying party".  Moreover, I think this should be done for V1.1 in both the Bindings and Profiles document and in the metadata (and anywhere else the terms are used).  It's really just a semantics issue.  But whenever we can use unambiguous terms (i.e. AP and RP) instead of potentially ambiguous terms, then I think we should do it. To illustrate my point...


In the current B/A Profile, we refer to the Asserting Party where the inter-site transfer service resides as the "source" site.  We refer to the Relying Party as the "destination" site.  So in this profile, it is the destination site that initiates a SAML Protocol exchange (samlp:Request) with the source site to retrieve an assertion.


But in the case of a general SAML Authority responding to an Attribute Query or an Authz Query, I think of the site where I initiate a query as the "source" site and the site responding to my query as the "destination" site.


Thus in one case the system where the SOAP Binding Service resides is the source site and in the other case it is the destination site.  I find this to be ambiguous.  I've run across this same issue before in other protocol work and find it is always better to use unambiguous terms where they exist.  We do have unambiguous terms - Asserting Party and Relying Party.


In the original work on the Bindings and Profiles document, was this issue previously raised and dismissed? I haven't searched the mail archive to look for anything on this.


In V1.0, it really was just a semantics issue with respect to the text of the document.  But with the metadata now being defined, the issue is making its way into a schema definition and that's really where I think we must be as unambiguous as possible.  I believe the metadata should eventually support more than just the web sso profiles where the source/destination terms aren't quite as ambiguous (although I could still debate that point a bit).



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

-----Original Message-----
From: Mishra, Prateek [mailto:
Sent: Thursday, January 23, 2003 5:10 PM
Philpott, Robert; 'security-services@lists.oasis-open.org'
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