Shibboleth Developers

["Scott Cantor" <>]

> So, when Phil complained, jan 13,
> 
>     "I now want to move our origin to 1.2.1 (which BTW, rocks),
>      but we'll kill all the TargetedIDs."
> 
> why your response,
> 
>     "The big nasty is when they go to 1.2,
>      then that part of the seed changes and you're dead."
> 
> and not just, "who cares?"

You're conflating technology, specs, and deployment policy and acting like
there's no distinction or that everything I say applies equally to all of
them. The specs mostly let you do whatever you want, and the technology has
to support that, but any reasonable use of the thing has to assume some
basic behavior, while still allowing ultimate authority to rest with the
user.

If you're expecting the values to be stable (subject to your own policy) and
then you upgrade some software and every single one of them changes with no
warning or reason, I see that as bad. I assume you do too, otherwise you
wouldn't have bothered to write all that code.

> why the concern?  What stability when the idp can effect changes at whim?

That's a question for InCommon. If people think tha giving users the right
to roll over the values to protect their privacy means they're useless, then
I guess Liberty's indeed wasted a lot of time, and we shouldn't waste time
on the attribute ourselves.

I think it's a little more gray than that.

> And in the definition, from the shib glossary,
> 
>     "Persistent Identifier (TargetedID): This special identifier
>      type allows an IdP and SP to preserve a single identifier
>      for one principal across all current and future transactions..."
> 
> am I to assume the words 'preserve' and 'future' mean only
> what an advertiser might mean by them?

I think the statement has no business in the Shib glossary, since any
promises belong to deployers, not software. Certainly the word "all" is way
too strong, common sense should tell us that.

> If there is no requirement on the persistence of ePTID then it
> would appear to be nothing more than a nicety, providing the user
> with a "pleasant browsing experience".

I fail to understand what kind of requirement you're asking for. The
attribute's definition itself now points out that peristence is relative, I
think. It doesn't mean forever. What's really persistent is the binding
between value and human. It will never mean a different human. It doesn't
mean that no other value for that human can exist.

> Maybe that's all it is
> and I've been way too concerned about our maintenance of them.
> Generation on the fly might be the best approach after all.

What you're really saying is that if there's no 100% guarantee that it's
unchanging, SPs can't use it, and I think that's a question for policy, and
is mostly not true even allowing for change.

As David said, if you really need linking (as opposed to recognition across
sessions for convenience), there's got to be a process to establish the link
in the first place, and changing the thing just results in the link being
recreated, whatever that entails. So, yeah, in that sense, you could
generate them on the fly and just ignore the complaints if everybody's link
suddenly disappears. But nobody wants to be on the other side of those
complaints.

-- Scott