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

["Cantor, Scott" <cantor.2@osu.edu>]

Note: the public review isn't open yet on this document, so take these as
informal responses.

On 9/22/11 11:10 AM, "Tom Scavo" <trscavo@gmail.com> wrote:
>
>Section 2.4
>
>Regarding the precedence rule in section 2.4.3 (<mdui:DisplayName> =>
><md:ServiceName> => entityID), what if there are multiple
><md:AttributeConsumingService> elements in SP metadata, that is,
>multiple <md:ServiceName> elements? The extension spec doesn't address
>this question.

It treats them as the same case.

>I don't think the <mdui:DisplayName> element should override
>*multiple* <md:ServiceName> elements since that would dilute the
>effectiveness of multiple <md:AttributeConsumingService> elements. I
>conclude, therefore, that the <mdui:DisplayName> element should not
>override a single <md:ServiceName> element. A completely different
>precedence rule is warranted.

There is no need for one. If you were to make ServiceName take precedence,
then there's no reason to have a DisplayName anyway. It's equivalent to
say "ignore it" or "don't use it" and we did the latter so that the rule
would be to favor DisplayName in both the IdP and SP cases.

>Here's another way to look at it. Suppose you have a 100% standard
><md:EntityDescriptor> that describes a physical SP composed of several
>logical SPs, each with its own <md:AttributeConsumingService> element.

SPs are logical constructs, not physical, but regardless, just don't use
DisplayName and you're fine.

>Now add an <mdui:DisplayName> extension element to SP metadata. If the
>IdP conforms to the extension spec, this breaks the UI at the IdP.
>Instead of displaying a different name for each logical SP, the IdP
>displays the same name for all. This is a bug.

No, it's a mistake by the metadata author. What matters it that it's
predictable, and it is.

>I'm not sure what's the best way to fix this problem. Sure seems like
><md:ServiceName> should take precedence over <mdui:DisplayName>, not
>vice versa. If so, what is the latter good for? As a name for the
>physical SP, I suppose, but I'm not sure if that's useful in practice.

Other than in all the current cases in which there is no
AttributeConsumingService?

The bug is that we overloaded service description with requested
attributes. Having done that and not being able to fix it without starting
over, the compromise was to say if you want to request attributes, you can
ignore part of the mdui work, and if not, it's there to use.

>If I read the extension spec correctly, the precedence rule applied to
>IdP metadata is simply <mdui:DisplayName> => entityID. This can't be
>intended.

It is.

> We've been using <md:OrganizationDisplayName> on discovery
>interfaces for years, but the latter doesn't even appear in the
>precedence rule. If this is intended, then I must beg to differ. It
>would seem that <mdui:DisplayName> in IdP metadata is of no use.

I was explicitly told by the authors of the input document that using
OrgDisplayName was a non-starter and should be kept out of the spec. It
doesn't represent the actual IdP "community" in many federations, and so
it's simply "something else".

As a legacy transition aid, we expect many discovery tools will continue
to use it, but that's an implementation choice, and the spec leaves it out
rather than codify a behavior people are trying to get away from. I
solicited input from the other authors on how to handle it, and their
choice was to just leave it out.

>Section 3.1
>
>Apparently, only a discovery service must conform to section 2.4.3.
>That's seems odd. Shouldn't the conformance requirements on lines
>390--391 and 392--393 be combined?

I don't think I understand your comment here. Lines 390-391 address
anything that consumes metadata, such as an SP or IdP.

-- Scott