Shibboleth Developers

["David L. Wasley" <>]

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