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


Prateek, I think you missed my point.  I acknowledged that the "source site" and "destination site" terms were used consistently in the SSO profiles.  But my point is that now the terms are being used in the metadata definitions.

 

If we will define one set of metadata for web sso profiles and a different set of metadata for other uses of saml, then perhaps there could be an argument for using the terms in the metadata.

 

But I think defining separate metadata for SSO and other metadata for other SAML usage is the wrong approach.  At least at this point, I think we should have one set of standard metadata for SAML. But of course I'm willing to listen to counter-arguments.  So if there is only one set of metadata, then the terms will end up getting used outside the scope of SSO.  Thus my example - when defining an authority's SOAP Binding Service URL it is in the "source site's" metadata. But if I'm just an attribute authority and not supporting Web SSO, the term "source site" doesn't mean anything to me. So where do I define the SOAP Binding Service URL?

 

Any clearer?

 

Perhaps what we need to do is come up with a clear set of goals and non-goals to guide the metadata work item before we go much further.  I'm certainly interested in participating in this (can you tell?).

 

Does anyone else have an opinion on this matter?

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:rphilpott@rsasecurity.com

-----Original Message-----
From: Mishra, Prateek [mailto:pmishra@netegrity.com]
Sent:
Friday, February 07, 2003 1:04 PM
To: Philpott, Robert; Mishra, Prateek; 'security-services@lists.oasis-open.org'
Subject: RE: [security-services] metadata and an ISSUE for 1.1 re: use of "source" and "destinatio n"

 

 

The terminology "source site" and "destination site" are only used for the web browser

profiles with extremely precise semantics.

They are NEVER used outside these profiles (confirmed via search

on cs-sstc-bindings-01 and cs-sstc-core-01) or in the core document. So I am genuinely puzzled by your

use of these terms to various other contexts.

 

Each profile may (and probably should) define additional terminology as needed. For example,  

the SAML SOAP binding defines the terms: SAML requester, SAML responder and provides

definitions for both in Section 3.1.2.1. 

 

A fair amount of effort went into selecting these terms in SAML 1.0. I see no evidence that these

terms have been misapplied within the specification or are leading to error.

 

I understand that

people may be using them innappropriately to other contexts. Is that the issue we should be addressing?

-----Original Message-----
From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
Sent: Friday, February 07, 2003 12:30 PM
To: Philpott, Robert; 'Mishra, Prateek'; 'security-services@lists.oasis-open.org'
Subject: 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:rphilpott@rsasecurity.com

-----Original Message-----
From: Philpott, Robert
Sent: Tuesday, February 04, 2003 6:19 PM
To: 'Mishra, Prateek'; 'security-services@lists.oasis-open.org'
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).

 

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:rphilpott@rsasecurity.com

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

  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:

    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.

 

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