Skip to Content.
Sympa Menu

shibboleth-dev - RE: TargetedID Durability

Subject: Shibboleth Developers

List archive

RE: TargetedID Durability


Chronological Thread 
  • From: "Alistair Young" <>
  • To:
  • Cc:
  • Subject: RE: TargetedID Durability
  • Date: Sun, 31 Jul 2005 17:52:06 +0100 (BST)
  • Importance: Normal

> if they are trying to access personal information at the SP.
I'm curious. Why would a user have personal information stored outwith
their IdP? Is it personal information in the sense that they created it,
say an ePortfolio or something, or personal information in the sense of
attributes, i.e. name/address etc?

Alistair


--
Alistair Young
Senior Software Engineer
UHI@Sabhal
Mòr Ostaig
Isle of Skye
Scotland

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




Archive powered by MHonArc 2.6.16.

Top of Page