On Mon, Oct 17, 2011 at 8:11 PM, Cantor, Scott <> wrote:
> On 10/17/11 6:57 PM, "Tom Scavo" <> 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.
