shibboleth-dev - comments: draft-mace-shibboleth-arch-protocols-03
Subject: Shibboleth Developers
List archive
- From: Tom Scavo <>
- To: Shibboleth Development <>
- Subject: comments: draft-mace-shibboleth-arch-protocols-03
- Date: Thu, 11 Nov 2004 13:25:41 -0500
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=EWWWS71mO5PcIcH6ZvBfp3L4vzBkytcbmrXD7TwIRuuptIccQp2YLH7yTrSSkLYd6j3B501dBm3yVWGrXkKKUvOCJ8y659KuIbGk0NmC2R5qsEHM58DeZIMSHUU8Y9JDMF7I4lP0ZK95ta5ccF9aPbtiKd+ncxOLsHqyLahmiqs=
Document: draft-mace-shibboleth-arch-protocols-03
(Scott, your writing is impeccable so please forgive my nitpicking :)
[line 19] Remove the hyphen from "attribute-exchange" (it's not used
anywhere else in the doc).
[line 72] Delete this blank line (and thus its corresponding blank page).
[line 77] The phrase "destination-site" uses legacy terminology.
[lines 88--89] Is the different font used on these lines intentional?
If so, why?
[lines 100, 102, 104, 106] Remove the period at the end of the line for
clarity.
[line 104] Is this URI still appropriate (assuming the emerging SAML
1.1 Metadata spec)?
[line 108] Insert a line break after the URI and remove the comma for clarity.
[line 125] The dashed line from User Agent to Identity Provider is not
optional.
[line 125] The diagram assumes the browser/POST profile and therefore
does not illustrate a possible back-channel exchange for artifact
resolution.
[line 136] Section reference is missing.
[line 151, 185, 211] The use of the word "or" is troublesome. The
SAML spec seems to require SSL/TLS in this case yet makes no mention
of digital signatures wrt SAML over SOAP over HTTP.
[line 165] Replace "service providers and initiates" with "service
providers. The SSO service initiates".
[line 166] Delete the phrase "(or itself acting as)".
[line 175, 190, 199] Replace "and/or" with "or".
[line 176] Replace "POST" with "Browser/POST".
[line 179] Replace "Artifact" with "Browser/Artifact".
[line 180] Replace "assertion consumer service and containing" with
"assertion consumer service. The redirection URL contains".
[line 182] Replace "SAML protocol" with "SAML SOAP protocol".
[line 191, 208, 609] Replace "Browser" with "browser".
[line 193] Append "respectively".
[line 196] Section reference is missing.
[line 227] Replace "section 3.1" with "section 3.1.1".
[line 228] Replace "SSO service; the WAYF" with "SSO service. The WAYF".
[lines 250--254] Elevate this subsection one level so that it applies
to all of section 3.1. (See comment below.)
[line 278] Delete the phrase "in accordance with the Browser/POST profile".
[line 286] Replace "URL" with "URL prefix".
[line 303] Replace "If it cannot or will not" with "If it cannot or
will not use this profile".
[line 399] Convert mixed-case identifier to lowercase.
[lines 422--426] The SAML spec requires that the IdP (not the SP)
enforce the artifact single-use rule. (I suspect this is easier to
implement anyway.)
[line 432] Replace "the redirection response" with "a redirection URL"
(since the given example is not a response).
[line 435] Replace "sp.example.org" with "sp.example.com" so that it
agrees with example 3.1.1.4.
[line 435] The SAML artifact is not URL-encoded and therefore bugged.
The fact that the artifact should be URL-encoded should be mentioned
in the text. In fact, the SAMLart parameter should be mentioned in
the text.
[line 437] Append "Protocols".
[line 458] Replace "http" with "https" (my mistake earlier, sorry).
[line 522] Append "See Example 3.1.2.1.".
[line 540, 546, 551] Replace "a case" with "cases".
[line 542] Insert "(See Example 3.2.2.1.)" between sentences.
[lines 557--558] Italicize "common domain".
[lines 558--559] Italicize "common domain cookie".
[line 563] Insert a major section break.
[line 564] Replace "SSTC" with "OASIS Security Services Technical Committee".
[line 597] Delete the phrase "that supports an Attribute Authority
service as described in section 2.1.2" since a compliant IdP MUST
support attribute request/response.
[line 614] Replace "it" with "the attacker".
General comments and suggestions:
- Major omission: Attribute Release Policies, especially content and
XML representation thereof. See Walter Hoehn's ARP spec
https://umdrive.memphis.edu/wassa/public/ARPs/arp.spec.html
for an introduction.
- What about persistent identifiers (referred to in GridShib)?
- Give a specific example of a back-channel exchange for artifact
resolution in section 3.1.3 (referred to as section 3.1.4 below).
- Combine sections 3.1 and 3.3, and add a subsection entitled
"Artifact Resolution Profile". For example:
3.1 Authentication Request and Response Profiles
3.1.1 Required Information
3.1.2 Authentication Request Profile
3.1.2.1 Message Format and Transmission
3.1.2.2 Processing Rules
3.1.2.3 Example
3.1.3 Authentication Response Profiles
3.1.3.1 Browser/POST Profile
3.1.3.1.1 Example
3.1.3.2 Browser/Artifact Profile
3.1.3.2.1 Example
3.1.4 Artifact Resolution Profile
3.1.5 Transient NameIdentifier Format
- Combine sections 3.2 and 3.4. For example:
3.2 Attribute Request and Response Profiles
3.2.1 Required Information
3.2.2 Attribute Request Profile
3.2.2.1 Example
3.2.3 Attribute Response Profile
3.2.3.1 Example
3.2.4 Attribute Values
- What happened to <md:AttributeConsumerDescriptor> in section 3.6?
- The URI urn:mace:shibboleth:1.0:profiles:SSO on line 594 seems
inadequate. Like SAML 2.0, why not specify a group of URIs:
urn:mace:shibboleth:1.0:bindings:HTTP-Redirect
urn:mace:shibboleth:1.0:bindings:HTTP-POST
urn:mace:shibboleth:1.0:bindings:HTTP-Artifact
urn:mace:shibboleth:1.0:bindings:SOAP
This would allow multiple <md:AssertionConsumerService> elements to be
differentiated, for example.
- Possible Shib-specific additions to the metadata specification:
WAYF, Common Domain, and ARP.
- [Note to myself: Consider lines 614--618 carefully.]
- Include a reference to [ShibConf] in section 5.
- comments: draft-mace-shibboleth-arch-protocols-03, Tom Scavo, 11/11/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-03, Scott Cantor, 11/11/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-03, Tom Scavo, 11/11/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-03, Scott Cantor, 11/11/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-03, Walter Hoehn, 11/11/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-03, Tom Scavo, 11/11/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-03, Scott Cantor, 11/11/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-03, Tom Scavo, 11/11/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-03, Scott Cantor, 11/11/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-03, Tom Scavo, 11/11/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-03, Scott Cantor, 11/11/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-03, Scott Cantor, 11/11/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-03, Tom Scavo, 11/16/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-03, Tom Scavo, 11/11/2004
- Re: comments: draft-mace-shibboleth-arch-protocols-03, RL 'Bob' Morgan, 11/11/2004
- RE: comments: draft-mace-shibboleth-arch-protocols-03, Scott Cantor, 11/11/2004
Archive powered by MHonArc 2.6.16.