- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Mon, 08 Oct 2012 21:54:46 +0100
- To: nathan@webr3.org
- CC: public-identity@w3.org
On 10/08/2012 05:43 PM, Nathan wrote:
> Stephen Farrell wrote:
>> I think there's definitely merit in investigating such approaches,
>> mainly because they don't need passwords, but also partly due to
>> the very thing to which you're objecting - any handling of user
>> names or identifiers can be part of the application and not a part
>> of some security infrastructure. (Maybe I've just developed too
>> many of those over the years:-)
>
> Am I correct in assuming that the general premise is that securing the
> connection
Well, s/securing the connection/authenticating the user agent/ or
something but...
> can be done with a keypair, and then at application level an
> identifier can be associated with a user, based on the keypair?
Yep.
> Then further to this, that each origin can be associated with a
> different keypair, such that a user isn't identifiable cross origin by
> using a single key as an identifier?
Right.
I've a maybe-cute/maybe-dumb idea for randomised key identifiers
if we're worried about correlations over time/paths between
the same UA and server. Haven't written it up yet though but its
fairly trivial: just send a set of {random-index,bitvalue} from
a key hash. 256 bits of that gives you 28 random bits of a hash
value, which'd be enough to identify one key most of the time
even for a big population.
S.
>
> Best,
>
> Nathan
>
>
Received on Monday, 8 October 2012 20:55:10 UTC