On Fri, 2014-02-21 at 21:55 +0000, John Horne wrote:
> On Fri, 2014-02-21 at 19:18 +0000, Sara Hopkins wrote:
> > Hi John,
> >
> > It's not obvious from that documentation, but I think that
> > deactivationDate is a mechanism for revoking a persistent ID. The
> > deactivationDate is the date at which the persistent ID should be
> > revoked. So, I don't know what date you set, but if it was today's date
> > or earlier, presumably it revoked the old persistent ID and gave you a
> > new one.
> >
> > The new one is different from the old one because (as it says on the
> > ResolverStoredIDDataConnector page) "Every subsequently generated ID for
> > a given user/IdP/SP triple, if the first one is revoked, is a Type 4 UUID."
> >
> > Does that make sense?
> >
> Yes. Not quite sure why but I had it in my mind that setting the
> deactivationDate would block a user to the SP.
>
> The old persistentId was: JsguCqpxqhI0I8741YnYhQY7QTM=
> The new one is: f6c79003-5c08-4056-8887-7b1728effd40
>
Interestingly, if I delete all my records from the local DB, then
Shibboleth reverts to creating an initial persistentId using the initial
algorithm.
Having done this my new persistentId is: JsguCqpxqhI0I8741YnYhQY7QTM=
Which is exactly the same as the very first one. It is persistent :-)
John.
--
----------------------------------------------------
John Horne Tel: +44 (0)1752 587287
Plymouth University, UK Fax: +44 (0)1752 587001
|