[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Discovery hint
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]