Don Park proposes generalizing the email mechanism (email gets sent to provided address, user clicks on embedded link) often used at registration and/or password recovery time into a true authentication mechanism.
Rather than do this only initially and then subsequently as occasionally necessary, the user would authenticate this way every time (or at least when cookie expiry made it necessary). No password necessary at the site, and so it's a kind of SSO based on the authentication to the email server. Nice.
Message delivery lags and spam filters could make the system impractical. In my experience, the 'Confirm Account' mail can arrive long after I try to register, which isn't an issue if the site lets me proceed in the interim, but would be an issue if it prevented me signing-in.
More fundamentally, it seems a step backwards. Current reality is that just about every site already has my email, and so Don's scheme wouldn't change the nature or scope of the info that I need share with sites in order to get service. But, I don't like this current reality. I don't want to have to give my email(s) out to all these sites, constantly doing the mental computation 'I'm never going to be back here so I'll use an email address with a high disposability factor'. Don's model reinforces this status quo.
As an aside, Don's model fits the pattern of challenge-response authentication - the site's challenge is 'Can you access this email account?' and the user's response is 'You bet (and proves it by clicking on the link)'. I'm surprised to see that SAML doesn't appear to provide an Authentication Context to describe this basic pattern. The only support for challenge-response in the Authentication Context schema is the SharedSecretChannelResponse element, and in Don's scheme, the email address is probably no secret.