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