Shibboleth Developers

["Alistair Young" <>]

ok, I see. Am I correct in thinking that such an SP will gather
information on the user and then tell the user, "go get some sort of
credential that I can associate with this info".

The user has an IdP, for the sole purpose of authentication and dishing
out a credential, such as ePTID.

So the user themself, in a one shot process, then has to assert to the SP
that "this is my ePTID and how do you know that's correct? Because I'm now
going to divulge to *you*, the SP, information that only *you* will know
about me".

So the SP then knows to trust an ePTID assertion from a particular IdP for
a particular user and to allow it to unlock personal info.

Seems really compilcated when the SP could just opt of Shibboleth and
provide a login service. Then again, Shibboleth doesn't support this so is
such a profile on the cards?

Alistair


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

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