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