[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...

----------------------------------

 
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).

 

Thoughts?

Rob Philpott 

RSA Security Inc. 

The Most Trusted Name in
e-Security 

Tel: 781-515-7115 

Mobile: 617-510-0893 

Fax: 781-515-7020 

mailto: 

-----Original Message-----

From: Mishra, Prateek [mailto:] 

Sent: Thursday, January 23, 2003
5:10 PM

To: Philpott, Robert;
''

Subject: 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