Shibboleth Developers

["David L. Wasley" <>]

At 5:30 PM -0400 on 7/29/05, Scott Cantor wrote:

> ....
>
> Since one of the reasons for making changes is to "wipe" the slate clean at
> an SP, it certainly isn't required in SAML that an SP know about it.
>
> -- Scott

Yes - and that means the SPprovidedID should NOT be used if the IdP 
wants to offer Subjects the ability to change ePTIDs.

That said, I agree with Scott that some of this discussion is 
"policy" as opposed to "technology."  However, the technology should 
not limit the options.

My perspective on this discussion and what at least one option should be:

1) Some SPs want a "persistent identifier" to use in an ACL.  It 
should not be changed capriciously by the IdP.  I see no need to 
change it at all except at the Subjects request.

2) The fundamental rule is that at least one type of ePTID must, by 
definition, never be assigned to a different physical person because 
otherwise it could violate an SP's ACL.  (I believe this rule is the 
current ePTID rule...)

3) If an SP cares, it will find a way to associate an ePTID with a 
specific physical person and will simply (re)invoke it if it sees an 
ePTID it doesn't recognize.  Presumably the Subject will understand 
why this is happening, e.g. if they are trying to access personal 
information at the SP.  On the other hand, if the SP uses the ePTID 
to maintain state for the Subject, then it is up to the Subject if 
s/he wants to break that "feature" or not.

3) That said, I believe privacy requires that
  (a) a different ePTID be used with each SP,
  (b) the IdP should -not- change the (persistent) ePTID without 
permission of the Subject, and
  (c) the Subject should be able to cease the use of a given ePTID 
and get a different one for that same SP -without- the new one being 
linked to the former SPprovidedID !!


        David