- From: Nathan <nathan@webr3.org>
- Date: Tue, 09 Oct 2012 11:01:43 +0100
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- CC: public-identity@w3.org
Stephen Farrell wrote:
>
> 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.
Sounds good, and anything that can be explained effectively so simply
and in such a short space has to be a good thing :)
Best,
Nathan
Received on Tuesday, 9 October 2012 10:02:49 UTC