 |
 |
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