Skip to Content.
Sympa Menu

shibboleth-dev - Discovery Service

Subject: Shibboleth Developers

List archive

Discovery Service


Chronological Thread 
  • From: "Tom Scavo" <>
  • To: "Shibboleth Development" <>
  • Subject: Discovery Service
  • Date: Sun, 29 Oct 2006 20:53:51 -0500
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=bt9PnyETeEcHRkmLuGhNa3Prav1kiw6NgjVQj44mTSuRirMTdN9b0YAXWuJcGWVvlpWNulcM1SDxOV/l6yG5WDOymXVgs3ZqXrp7hdNXbegIllYeU/VgvdWcJYVbw2TUkq5wyBr5SQhL8+aICk6etz0Lvd4TC//B2ZGSDqKNlvs=

Some links to development notes have appeared on the Shib 2 Roadmap:

https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/ShibTwoRoadmap

These notes are much appreciated, thanks. One topic in particular
caught my eye:

https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/WAYFDev

Is this a design for a per-SP discovery service? This seems to be the
case since the protocol doesn't require the unique identifier of an
SP. Also, since the return URL is arbitrary, how do you prevent a
rogue SP from spoofing the user to divulge their preferred IdP?

I'm not sure what a "SAML IdP cookie" is, but does this service
support the SAML2 Common Domain Cookie (CDC)? Will the CDC Reading
and Writing Services be implemented? (It sure would be nice to have
servlet filters that implemented the CDC Reading/Writing Services.)

To integrate with the SessionInitiator at the SP, would it be better
to call the output parameter 'providerId' instead of 'entityID'? Then
the return URL could point to a (lazy) SessionInitiator endpoint (or
maybe I'm misunderstanding the purpose of this new service).

Thanks,
Tom



Archive powered by MHonArc 2.6.16.

Top of Page