Skip to Content.
Sympa Menu

shibboleth-dev - comments: draft-mace-shibboleth-arch-protocols-03

Subject: Shibboleth Developers

List archive

comments: draft-mace-shibboleth-arch-protocols-03


Chronological Thread 
  • 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.



Archive powered by MHonArc 2.6.16.

Top of Page