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:]
Sent: Friday, February 07, 2003
12:30 PM
To: Philpott, Robert; 'Mishra, Prateek';
''
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:
-----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
