Subject: Re: [security-services-comment] comments re sstc-saml-metadata-ui-v1.0-csprd01
On Mon, Oct 17, 2011 at 8:11 PM, Cantor, Scott <firstname.lastname@example.org> wrote: > On 10/17/11 6:57 PM, "Tom Scavo" <email@example.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.