RE: [security-services] metadata and an ISSUE for 1.1 re: use of"source" and "destinatio n"

Re: "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)."

 

Arghh... my statement about ambiguity
was ambiguous L - the "aren't quite as ambiguous" phrase was
recognizing the fact that the web sso profiles use the terms consistently, but
other SAML uses are what causes the ambiguity.  Specifically, for an AttributeQuery
request/response, "source" and "destination" are not as
clear.  Thus if I'm defining the SOAP Binding Service URL, does it get
defined in the source site info or the destination site info.

 

I know that when we started talking about
defining metadata, we said we would start it based on the info learned from the
web sso interop. That made sense and Prateek did a great job of getting the
ball rolling. However, I didn't think then (nor now) that the metadata
was thus just going to be limited to web sso usage.  I would really like
to see the metadata encompass the various uses (not just sso) for which SAML
can be used.  

 

Source and destination are not terms
defined in our glossary and as I mentioned, I think we should make sure they
aren't used in the specs. When we talk about metadata related to assertions,
I think we should use terms "asserting party" and "relying
party".  When we talk about protocol metadata, I think the terms
should be "requester" and "responder" (yes - my thinking
has evolved on this a bit since my original mail).  

 

I'd like to have a discussion on
this topic at the next meeting.

 

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: Philpott, Robert 

Sent: Tuesday, February 04, 2003
6:19 PM

To: 'Mishra, Prateek';
''

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

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

 
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