Shibboleth Developers

["David L. Wasley" <>]

I think you miss the point.  There are 2 parts to 
being an IdP: (1) knowing something about a 
person, (2) issuing and maintaining a credential 
of some sort that links to this information.  In 
the scenario I presented, the SP does the first; 
the IdP does the second.  The wrinkle is that the 
link isn't established until the Subject does 
something to make it so.

Yes - there is "trust" in this scenario.  The SP 
trusts the IdP to (a) issue a reasonable strong 
credential, (b) generate and maintain a unique 
identifier for that person, (c) never assert that 
identifier for a different person, (d) protect 
their system well enough that this "identity" 
can't be stolen, (e) etc.

Why doesn't the Internal Revenue Service simply 
trust the IdP to assert that the Subject is "John 
Smith"?  Well, because that isn't sufficient. 
How about asserting "tax payer ID number"?  Well, 
because the IdP isn't authoritative for that.

So why federate?  So the SP doesn't have to run a credentialing service.

        David

-----
At 7:15 PM +0100 on 7/31/05, Alistair Young wrote:

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