shibboleth-dev - Discovery Service
Subject: Shibboleth Developers
List archive
- 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
- Discovery Service, Tom Scavo, 10/29/2006
- Re: Discovery Service, Chad La Joie, 10/29/2006
- RE: Discovery Service, Scott Cantor, 10/29/2006
- <Possible follow-up(s)>
- RE: Discovery Service, Scott Cantor, 10/30/2006
Archive powered by MHonArc 2.6.16.