Public Comments

The following documents underwent Public Review between 14 Oct 2011 and 13 Nov 2011:

See the OASIS official announcement for details about this Public Review.

The comments received during the Public Review period are itemized below.

SAML V2.0 Metadata Extensions for Login and Discovery User Interface Version 1.0

The following comments were received:

Comment 1

Reference

http://lists.oasis-open.org/archives/security-services-comment/201110/msg00004.html

From
Tom Scavo
Comment
The document contains no line numbers and is therefore difficult to reference.
Disposition
Line numbering is not an OASIS requirement, but future versions will hopefully include them. Actual document prep for official versions is no longer under TC/editor control.


Comment

Since type mdui:UIInfoType is defined with minOccurs="0", an empty <mdui:UIInfo/> element is allowed. Is this intentional? Seems like such an element should be avoided. Same comment for type mdui:DiscoHintsType.

Disposition
XSD can't handle what we would have to specify since none of the individual children should be required. Will add prose precluding an empty element.

Comment 2

Reference

http://lists.oasis-open.org/archives/security-services-comment/201110/msg00012.html

From
Tom Scavo
Comment
Section 1.2, the formatting of references is all screwed up.
Disposition
I see no egregious issues with the references, but even if there were, it's not under our control, TC Admin deals with document conversion now. I don't believe we can afford to care about formatting issues henceforth until the process is materially different than it now is. If it's readable, that's all we can shoot for.


Comment
Section 1.2, where is the reference to the schema document?
Disposition
The OASIS document process no longer allows for such references because the document maturity level ends up out of sync. Designated cross reference motions are not permitted to be used for this purpose because the schema is considered part of the enclosing specification, so it can't be referred to by the motion. This will be true of all specs. The schema is just part of the package being reviewed (which is why it's in the ZIP file).


Comment
Section 2.1, s/proscriptive/prescriptive/
Disposition
Accepted.


Comment
Section 2.1.1, s/Localized names/A localized name/
Disposition
Accepted.


Comment
Section 2.1.1, s/Localized descriptions/A localized description/
Disposition
Accepted.


Comment
Section 2.1.1, s/Localized logo graphic/A localized logo image/
Disposition
Accepted.


Comment
Section 2.1.1, s/URLs to localized information/A URL to localized information/g
Disposition
Accepted.


Comment
Section 2.1.2, s/a set of localized names/a localized name/
Disposition
Accepted.


Comment
Section 2.1.4, s/md:KeywordsType/mdui:KeywordsType/
Disposition
Accepted.


Comment
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?
Disposition
The width and height are meant to be used directly by the consumer to express the size of the image in HTML. A vector image may work at many sizes, but the consumer is not expected to care about that. Text will be added to clarify this.


Comment
Section 2.2, s/information which may hint/information that hints/
Disposition
Accepted.


Comment
Section 2.2, 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?
Disposition
We should add text advising against that to be consistent with the intent of the discovery protocol.


Comment
Section 2.2.1, s/information which may/information that may/
Disposition
Accepted.


Comment
Section 2.2.1, - s/determining with which identity provider(s) the user may be associated/determining which identity provider(s) the user may be associated with/
Disposition
I prefer to avoid ending with prepositions if the sentence isn't too awkward without them.


Comment
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?
Disposition
It says nothing about using other notations, the reference to the RFC seems explicit to me. The requirement being imposed is that you can't just support IPv4.


Comment

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.

Disposition
I think section 2.4.2 is explicit about the issues being the same with regard to both names and descriptions. I do think we should say something about the ability to simply omit the MDUI level elements in favor of the originals though.


Comment

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.

Disposition
This was done to directly meet the requirements of communities that do not use the element in their discovery interfaces. They explicitly requested we not include it as a part of the precedence rules to discourage future use of the element in that capacity. Implementations are free to continue supporting it as they see fit.


Comment
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.
Disposition
An example will be added.


Comment

Section 2.4.3, 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.

Disposition
It complicates nothing at the IdP, where it is well-defined and simple to handle, but it does not accomodate discovery protocols that don't have the ability to reflect which service element is in use, I agree. This will be noted.


Comment

Section 2.4.3, 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.

Disposition

If you use the <md:AttributeConsumingService> element, then you can omit mdui:DisplayName entirely if you're prepared to use <md:ServiceName> in the context of any given request. It would be impossible to precisely define when one or the other would be used if both are present, so having a firm rule that favors one over the other is more appropriate. The only gap I see is the ability to handle multiple service elements with centralized discovery. I don't believe in encouraging centralized discovery anyway, but at the end of the day, that's a problem with the discovery protocol, not this spec.


Comment
There's no space between paragraphs, which makes the text difficult to read.
Disposition
We don't control document formatting any longer.

Comment 3

Reference

http://lists.oasis-open.org/archives/security-services-comment/201110/msg00014.html

From
Tom Scavo
Comment

I see why you've specified the use of a plus sign (+) in multi-word keywords, but that may be tricky when using keywords as search terms in a search query. Almost all search syntaxes that I've seen use double quotes for that purpose. As a specific example, look at MDX (http://tools.ietf.org/html/draft-lajoie-md-query), which uses the plus sign (+) to separate search terms. Not sure what to do in the situation where a search term is one of your multi-word keywords. Maybe that's an MDX problem, not yours, I don't know.

Disposition
We don't want to impose complexity here by using quoting, which isn't recognized by XML list types anyway. We'd collide with something no matter what we use, so whatever the target environment is should define escaping as it sees fit. We do stipulate that there's no way to embed a '+' into a keyword on this end, but that hasn't been seen as a concern.

PublicComments20111014-20111113 (last edited 2011-11-01 16:11:14 by cantor.2)