Re: [security-services-comment] comments re sstc-saml-metadata-ui-v1.0-csprd01

[Tom Scavo <trscavo@gmail.com>]

On Mon, Oct 17, 2011 at 8:11 PM, Cantor, Scott <cantor.2@osu.edu> wrote:
> On 10/17/11 6:57 PM, "Tom Scavo" <trscavo@gmail.com> wrote:
>
>>The following are some preliminary comments regarding
>>sstc-saml-metadata-ui-v1.0-csprd01 (26 July 2011).
>>
>>***The document does not contain any line numbers so I'm not sure what
>>you want me to do. Can you please provide an official version of the
>>document with line numbers? Please advise.
>
> We have nothing to do with prepping documents anymore, that's up to TC
> admin. It isn't going to get fixed quickly if at all, so my advice is to
> refer to section numbers, or perhaps use the Open Office source directly.

Okay, here are my comments organized by section:

Section 1.2

- The formatting of references is all screwed up.

- Where is the reference to the schema document?

Section 2.1

- s/proscriptive/prescriptive/      (?)

Section 2.1.1

- s/Localized names/A localized name/

- s/Localized descriptions/A localized description/

- s/Localized logo graphic/A localized logo image/

- s/URLs to localized information/A URL to localized information/g

Section 2.1.2

- s/a set of localized names/a localized name/

Section 2.1.4

- s/md:KeywordsType/mdui:KeywordsType/

Section 2.1.5

- Summarizing discussion found elsewhere in this thread, if width and
height are the actual width and height (in pixels) of a bitmapped
image, what are the meanings of width and height for a vector image?

Section 2.2

- s/information which may hint/information that hint/

- What if the discovery service is prevented from interacting with the
user (isPassive)? Should (or may) the service rely on hinting
information in this case?

Section 2.2.1

- s/information which may/information that may/

- s/determining with which identity provider(s) the user may be
associated/determining which identity provider(s) the user may be
associated with/

Section 2.2.2

- It says that "IPv4 and IPv6 CIDR blocks MUST be supported." So other
notations may be used? Won't that lead to non-interoperability?

Section 2.4

- This section motivates a precedence rule for <mdui:DisplayName> vs
<md:ServiceName> but it fails to adequately distinguish between
<mdui:Description> vs <md:ServiceDescription>. One can infer the
author's intention by analogy but perhaps the relationship between
<mdui:Description> vs <md:ServiceDescription> should be made explicit.

Section 2.4.1

- The current use of <md:OrganizationDisplayName> in discovery
interfaces is (correctly) noted but then the precedence rule ignores
it entirely, which (if adopted) essentially breaks every discovery
interface on the planet. I strongly advise against such a strategy.

Section 2.4.2

- In the phrase "a name and description for the service itself," I
don't know what you mean by "the service itself." An example or use
case may help clarify the author's intent.

Section 2.4.3

- FWIW, I've recently implemented the following precedence rules:

IdP: <mdui:DisplayName> => <md:OrganizationDisplayName> => entityID

SP: <mdui:DisplayName> => <md:ServiceName> => entityID

Note that the precedence rules for IdPs and SPs are not the same, and
that an IdP falls back on <md:OrganizationDisplayName> for backwards
compatibility with existing discovery interfaces.

- The precedence rule given, and even the alternative rules suggested
above, do not address multiple <md:AttributeConsumingService>
elements, which implies multiple <md:ServiceName> elements. This
potentially complicates ANY precedence rule. This issue deserves some
discussion in this section.

- One approach to the above problem is to always use the value of an
<md:ServiceName> element on an explicit user consent page but to use
the value of the <mdui:DisplayName> element elsewhere, such as on the
IdP login page.

General

- There's no space between paragraphs, which makes the text difficult to read.