Josh Howlett wrote on 2010-01-13:
> However, it subsequently occurred to me that there might be some value
> in making this element more general purpose, to support other types of
> discovery 'hints' other than Kerberos; for example, IP address.
The difference is somewhat academic since the only difference would be
whether there's a single container element inside Extensions or multiple
discrete elements.
> A metadata consumer (e.g., a service provider or discovery service)
> could use this information to identify a candidate IdP(s) that the
> user agent should be redirected to. In terms of realising this, I was
> thinking that the sstc-saml-idp-discovery could be extended to specify
> a base 'list of hints' element, and then its child technology-specific
> hints could be specified in other profiles (e.g., the Kerberos hint in
> the Kerberos Web SSO profile).
I'm not sure that would be the right place, since this mechanism is really
distinct from the use of a third party discovery service. An SP doing
discovery itself, as is becoming the expected/preferred outcome, would also
have use for the hints. And in any case it would just be a totally distinct
part of that document, so other than a little virtual paper savings, I don't
think it matters.
I lean towards thinking it's not worth much to define a wrapper element that
all subsequent work would have to reference, given that anything in it would
have to be recognized explicitly at runtime by implementations anyway. Just
my opinion, I don't feel that strongly either way.
-- Scott
