Shibboleth Developers

[Tom Scavo <>]

Yes, I'm not getting my point across (or vice versa) so I'll keep
trying until there's a meeting of the minds somewhere along the way.
:-)

The profile specifies that the common domain cookie writing service is
invoked after the principal is authenticated by the local authn
service.  Now the authn event is out of scope and as far as I can tell
the invocation of the cookie writing service is out of scope as well. 
That doesn't leave much for the IdP to "support", I'm afraid!

Given what I know about typical authn services, I could imagine that
the IdP might redirect to the local authn service with a parameter
that targets the cookie writing service, something like this:

  https://idp.com/auth/controller?action=login&target=target

  where target = https://idp.cd.com/write?providerId=id&target=target

  where target = https://idp.com/shibboleth/SSO?RelayState=token

So after the authn event occurs, the cookie is updated, and the client
ends up back at the SSO service so that the message flow can continue.

None of this process is managed by the IdP, and moreover, it is all
out of scope!  What could possibly be "supported" by the IdP?  The
only thing I can think of is the redirect URL of the cookie writing
service, which might be stored in metadata, but I don't believe that
particular use of metadata is specified.

So I'm back to the same question as before:  In what sense MUST the
IdP support the IdP Discovery profile?

Thanks for bearing with me on this issue!  Tom

On Wed, 10 Nov 2004 16:42:17 -0500, Scott Cantor 
<>
 wrote:
> > If the IdP Discovery profile is not implemented, then there is no
> > common domain.
> 
> You'll have to define "not implemented", you're just stating a
> tautology...if it's not implemented, then it can't be implemented....
> 
> A common domain is configured into the implementation, but it doesn't exist
> or not exist based on whether somebody writes code to support it in the
> products they release.
> 
> > 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?
> 
> Support in the code is the issue. You're still confusing this with a set of
> deployment decisions, or I'm totally not getting your point.
> 
> > 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?
> 
> I'm assuming they have code and configuration machinery to interface with
> the common domain if it exists for a deployment. Nothing more or less. If
> they want to actually provide some of the machinery for the common domain,
> they could, but it's not clearly their role to do this.
> 
> Let me note that SAMLv2 specifies a conformant IdP MUST implement support
> for the profile, as did ID-FF. This isn't me inventing the idea.
> 
> The WAYF is the only new entity here, and since it compliments the profile
> by design, it's simply common sense to me that it would also help support
> it, mostly by either implementing the common domain service or at least by
> using it to establish the "remember my choice" cookie.
> 
> -- Scott
> 
>