Shibboleth Developers

["David L. Wasley" <>]

Scott, Interesting models but for somewhat different purposes, I think.
-----
At 9:09 AM -0400 on 9/25/03, Scott Cantor wrote:

>  > 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".
>
> Isn't that an authentication service?

Not quite the same thing.  For example, I might have a very "strong" 
PKI credential (i.e. I&A was thorough at the time of issuance) but 
the relying party can't know whether I've unlocked my private key 5 
minutes ago or 5 days ago.  If it can ask for another, additional 
authentication action and at the time it is important to know, then I 
believe it raises the comfort level somewhat.  In other words, it 
becomes a kind of multi-factor authentication where one of the 
"factors" is acquired in real time as needed.

> >  If a SSS makes sense, could that concept be integrated into a
> >  Shib environment?
>
> Well, you've got a handful of things that address presence in Liberty:
>
> Proof by an SP that the user signed on to the site at such and such a time.

But you still don't know when the credential was unlocked ...

> The ability to force reauthentication from the SP (which of course can't
> insure actual user interaction given things like password caching).

This is similar to what I am proposing, however I am proposing an 
auxiliary authentication action, not merely reaffirmation of the 
original authentication.  If a shared secret isn't good enough, then 
use something like a SecureID card.  (That can be lost or stolen but 
then we're not protecting Fort Knox (yet))

> An actual "interaction" service designed to support users stepping into a
> transaction at a site to provide consent. This is conceptually similar to
> what Shib envisioned for real time attribute release.

This could provide a similar service but in terms of AuthN per se 
gets back to the need for one-one pre arrangements.  That's why I 
came up with the notion of a 'shared pre arrangement' -- a service 
that is auxiliary to the fundamental AuthN in that it provides 
additional "factors" but which could be used by any number of 
different relying parties whenever it was needed.

        David



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

   http://archives.internet2.edu/

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