Michael White wrote:

> Since no-one has said that going with PersistentIDAttributeDefinition is
> a bad idea, I'm more than happy to go with this as it is, after all, the
> approach currently recommended by the UK Federation :-).

This is quite a complicated area, and there are some subtleties so
that's not _quite_ how I'd express the UK federation recommendation.

I'd recommend reading the reference Fiona pointed to, but in summary
there are two pretty much orthogonal questions about targeted IDs:

* where you get the values from (computed each time vs. computed once
then stored)

* in what format you transmit them to the SP (old style vs. new style)

The two options described in the resolver.xml file in current Shibboleth
IdPs distinguish between what I'm calling here "old style" and "new
style" (PersistentIDAttributeDefinition and SAML2PersistentID
respectively).  They are *both* computed-each-time rather than
computed-once-then-stored approaches.

Our recommendation is for identity providers to use "old style" when
transmitting targeted ID values, because that style is universally
understood by SPs and "new style" isn't (yet).  Our recommendations for
SPs are more complicated, but the gist is to plan ahead to allow either
"old style" or "new style" to be accepted as equivalent.

We don't in fact recommend that people use a compute-each-time approach
to generating ePTI values.  The wording in the Technical Recommendations
is intended to lean in the direction of getting people to use the more
flexible storage-based methods.  We would have made a stronger
recommendation to go down that route if it wasn't so hard to find an
implementation of this approach that people could use.

> I am, though, also interested in the idea of investigating the database
> approach for eduPersonTargetedID (we're still very early in our
> implementation, so plenty of time to change tack!) - is there anyone out
> there already doing this who would be willing to share what you've done
> (code, DB schemas, resolver configuration etc would be nice :-) ) to
> give the rest of us a leg-up?

As John and others have found, there isn't really an easy answer to this
to be found out there.  It's certainly a growing area of interest,
though, so if anyone *does* find an implementation out there that can be
adapted for general use then I'd very much like to hear about it so that
we can point to it in the federation documentation.

	-- Ian