Shibboleth Developers

["Alistair Young" <>]

> There are lots of services that necessarily
> maintain information about you
are these not IdPs? How much information can an SP store on you before it
becomes an IdP?

> they will require that I answer enough questions
> "that only I should know the answers to" in order
> to establish the mapping.
so they're basically re-authenticating you outwith your IdP? So there's no
trust involved in this scenario? The SP is saying "your IdP says you have
this ePTID but I don't believe it"

So in such a system, you would have an IdP which an SP treats with caution
and overlays it's own authentication above that of the IdP?

Why federate such a service in the first place?

Alistair

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

> Medical services; Social Security Administration; IRS; etc...
>
> There are lots of services that necessarily
> maintain information about you  Some -may- be
> willing to accept that an IdP can issue a
> reliable credential and offer a unique,
> persistent identifier but that may -not- be
> willing to accept an assertion of a mapping of
> that identifier to a particular database record.
> I.e. the IRS may be willing to accept an ePTID
> from my IdP but will use it only to enroll me -
> they will require that I answer enough questions
> "that only I should know the answers to" in order
> to establish the mapping.  After that, they -may-
> be willing to accept that same ePTID to enable
> access to the same database record.  Why would
> they do this?  To avoid the hassles of
> maintaining a user credentialing system and to
> provide a convenience for their users.
>
> BTW, this is not entirely theoretical.  See
> http://www.cio.gov/eauthentication
>
>       David
>
> -----
> At 5:52 PM +0100 on 7/31/05, Alistair Young wrote:
>
>>  > 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
>>>
>>>
>
>