Shibboleth Developers

["David L. Wasley" <>]

Ah, yes - "presence" - the bugaboo of SSO...

Clearly presence is important sometimes and not at other times.  So 
who decides when?  Logically I think it would be the relying party.

I've been thinking about a "service" that would verify that the Human 
Being (user) knows a shared secret at any point in time, on demand. 
A relying party could invoke the "SSS" to verify "presence", for 
example, at the time a transaction is being finalized, etc.  The SSS 
would reply "yes" or "no".

In the PKI environment, I can imagine the RA asking the user to 
provide a "pass phrase" at the time they register for a cert.  The RA 
would then also run the SSS.  The relying party would redirect the 
user to the SSS (perhaps by way of the HS...) and expect the SSS to 
return with a signed answer when it redirects the user back.

The shared secret might be the reading on a SecureID device, for 
example, for very highly sensitive applications.

If a SSS makes sense, could that concept be integrated into a Shib 
environment?

        David


-----
At 5:45 PM -0400 on 9/24/03, Scott Cantor wrote:

>  > If the requester is not "known" to the AA, it should return only
> >  "public information" that it would give to anyone.  What this
> >  information might be is a local decision.
>
> Yes, but if I can authenticate to the AA, I have no easy evidence as to why
> I'm asking for the user's attributes (proof of his presence). LDAP doesn't
> address that either, that's why I characterized the AA as basically an
> equivalent kind of service if you take the handle away (minus the searching,
> we're certainly not going there).
>
> -- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--