Skip to Content.
Sympa Menu

shibboleth-dev - Re: comments: draft-mace-shibboleth-arch-conformance-01

Subject: Shibboleth Developers

List archive

Re: comments: draft-mace-shibboleth-arch-conformance-01


Chronological Thread 
  • From: Tom Scavo <>
  • To: Scott Cantor <>
  • Cc: Shibboleth Development <>
  • Subject: Re: comments: draft-mace-shibboleth-arch-conformance-01
  • Date: Wed, 10 Nov 2004 16:26:27 -0500
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=MHgYvMt/uzqLuG/APQcy6AWUMkgAW/+11anBY+bYJCVFWMBLpy2vys2BmABA57ICX4I5ansDMHDjiSMQ8zlN67sFtuQLFV/vCJ2xktmoyjfQy1XPAfRjDfV3mC7555FpSunuaRo/rvH7UjXB2/sEicdNcb5yScSOTWevRpLMLqs=

If the IdP Discovery profile is not implemented, then there is no
common domain. If there is no common domain, the IdP can not take
advantage of a cookie writing service. Likewise an SP (or WAYF) can
not rely on a cookie reading service. In other words, what exactly is
there to "support" if no common domain exists?

The IdP Discovery profile defines a common domain and a common domain
cookie format, along with reading and writing services based on that
cookie. If you remove the common domain, you remove everything of any
consequence wrt IdP Discovery. That is, there is nothing left to
support!

So my original question still stands: In what sense MUST the IdP and
WAYF "support" IdP Discovery?

Are you assuming that the IdP and SP manage the cookie writing service
and cookie reading service, respectively? If so, where in the profile
is this implied?

Thanks,
Tom


On Wed, 10 Nov 2004 15:45:21 -0500, Scott Cantor
<>
wrote:
> > - Since a WAYF is essentially a proxy for the SP, why MUST a WAYF
> > support IdP Discovery? Shouldn't this be OPTIONAL (just like the SP)?
>
> WAYFs are intrinsically about IdP discovery. Not implementing the profile
> would be a needless limitation.
>
> SPs may not use a WAYF at all (many in fact) because they address the
> problem themselves, usually because the list of business partners is smaller
> than the list of trusted IdPs.
>
> SP implementations are likely to be influenced by the application
> environment, and sometimes discovery won't be an issue. It's arguable
> whether that consideration is enough to make the profile OPTIONAL, but
> that's why it's a draft.
>
> > - If the IdP Discovery profile is optional, why is the IdP required to
> > support it?
>
> Optional for one role doesn't mean it has to be optional for another. IdPs
> implementations should support configuration of a common domain URL and a
> mechanism to set the cookie after authentication.
>
> > Indeed, if IdP Discovery is not implemented, then
> > presumably there is no common domain and therefore no common domain
> > server for the IdP to interact with. So, in what sense MUST the IdP
> > support IdP Discovery?
>
> I think you're confusing deployment with conformance. Mandatory to implement
> does not mean mandatory to use.
>
> -- Scott
>
>



Archive powered by MHonArc 2.6.16.

Top of Page