Assurance Enhancements for IdPv2

[Caskey, Paul]

One thing that was sort of neat about Duo was that you could consider a NACK of the Duo push to be an account compromise (I think it was Duo who mentioned this).  In other words, if my phone lights up and I didn't cause it, then it means my account has been compromised and when I click the red button, our security group should be automatically alerted.

If that same dialog is also used for consent, it takes that other security functionality away if I NACK (perhaps).

Just my 2 cents...

> -----Original Message-----
> From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net]
> On Behalf Of Tom Scavo
> Sent: Friday, May 17, 2013 3:49 PM
> To: Shib Dev
> Subject: Re: Assurance Enhancements for IdPv2
> 
> Hi Bill,
> 
> On Fri, May 17, 2013 at 3:00 PM, William G. Thompson, Jr.
> <wgthom at gmail.com> wrote:
> >
> > Any other thoughts on potential implementation paths...
> 
> One thought is to separate the two factors such that the second factor is
> handled by the Unicon post-login handler. In this way, user attributes would
> be available to the post-login handler so that user consent could occur in
> conjunction with authentication via the second factor (two birds with one
> stone :)
> 
> Let me give an explicit example. Suppose the second factor is Duo Push. The
> post-login handler could pass the resolved user attributes to the Duo Service
> so that they are displayed on the user's mobile device. In effect, the user
> approves the authentication step and attribute release at the same time.
> Since Duo Push depends on a public-private key pair, the attributes could
> even be encrypted in transit.
> 
> Just a thought,
> 
> Tom
> --
> To unsubscribe from this list send an email to dev-
> unsubscribe at shibboleth.net