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