The Shibboleth developers have been discussing this and are very much aware
of the issues associated with requiring a database for deployment at any
scale of deployment other that the very largest.
The Shibboleth team are unwilling to ever commit to code until it has been
written and proven, but currently there is a plan which will not require a
database for IdP deployment (indeed I would say that for as far as I am
concerned this is a non-goal). My personal view is that there is no reason
to assume that this plan or a derivative cannot and will not be delivered
ComputedID is going away, but the function it currently provides (including
backwards compatibility from 1.3) will still be there one way of another and
no databases will be assumed.
Further, part of the "next major release" story is that tools will be
provided to seamlessly move from the current version of configuration to
future versions (so moving and IdP from 2.x to 3.x will be only marginally
more difficult than moving from 2.x.y to 2.x.z).
Apologies for the delayed follow-up, we wanted a chance to discuss this face
> -----Original Message-----
> From: Discussion list for Shibboleth developments [mailto:JISC-
> [log in to unmask]] On Behalf Of Andy Swiffin
> Sent: 11 March 2010 13:30
> To: [log in to unmask]
> Subject: Computed ID - will be removed at the next major shib release
> When I migrated to Shibboleth 2 I looked briefly at the Stored ID data
> connector as a source for targetted/persistent ID generation before
> it in favour of continuing with computed ID.
> The additional complexity of adding a database to the shibboleth mix
> unwarranted for what we would gain. I had noted that the documentation
> computed ID for shib 2 said at the start (in red, after a no entry symbol)
> "This data connector is deprecated. The stored ID data connector should be
> used instead." But like all of us I had a job to get done (amongst many
> others) and needed to get the migration to shib 2 sorted.
> The rather strong use of deprecated continued to nag at me and in a
> with someone else about their Shib 2 migration it came up again very
> so I thought I'd ask on the Internet 2 list why the word was used and what
> the problem with continuing to use computedID.
> I received a quick response from Chad La Joie to say:
> " that word was used because that's the exact
> status of that plugin. It will be removed in the next major release of
> the IdP.
> In addition, the next major release of the IdP will incorporate
> attribute release consent functionality (i.e. uApprove) which will also
> require a database."
> While I think the (optional) addition of uApprove type functionality is a
> thing, to make the deployment of a database an obligatory part of an IdP
> well raise the complexity ( perceived or actual ? ) to the point where
> people will just not adopt it. Having been involved in encouraging
> perhaps smaller and less well staffed, institutions to deploy their own
> am only too aware of how daunting a task it can appear.
> I am wondering what other people think of this?
> I, myself, am quite happy to use computed ID, I see no need to have a
> tied in as well with the IdP here.
> Andy Swiffin
> Please consider the environment. Do you really need to print this email?