Re: [saag] [http-auth] [websec] [kitten] HTTP authentication: the next generation

From: Richard L. Barnes <rbarnes@bbn.com> · Date: Mon, 13 Dec 2010 15:18:33 -0500

Actually, sounds like it might be a handy usage of OAuth.  The whole point of that protocol is to delegate user authorizations.  This is just the case where the user is delegating his entire set of authorizations to another instance of himself.
--Richard

On Dec 13, 2010, at 11:27 AM, Stephen Farrell wrote:

> 
> 
> On 13/12/10 15:29, Yoav Nir wrote:
> 
>>    * A possible solution to the first problem would be to issue
>>      multiple certificates for use in phone, laptop and desktop. But
>>      this makes the management of all these certificates even more
>>      complicated, and increases the attack surface.
> 
> Just a random thought. What if there were a standard way for web server
> apps to bind together different client public keys? E.g. start at home,
> with TLS mutual auth somehow, then go to the standard "bind new device"
> button which returns a shortish URL that the user can cut'n'paste to
> a 2nd device, also using TLS mutual auth, but with the key pair from
> that 2nd device. Then the server could associate a set of client public
> keys with the same account. (The URL could probably also be made only
> usable on that server as well via some server-side symmetric crypto
> maybe.)
> 
> Probably has holes galore, (and/or was tried a decade ago;-) but at
> least the browsers could work as-is. Well, as-is if you assume people
> had a way to generate and manage key pairs easily in their various
> browsers.
> 
> Regardless of the above, I think that if there were a usable way to
> do TLS mutual auth that was unencumbered and worked well, (including
> tackling portability), that'd be great, and even if the probability
> of failing is high, trying for that is maybe worth a shot.
> 
> S.
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag