On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:
As currently described, I oppose creation of this working
group on the basis that it enables and seemingly encourages
embedding identifiers for humans as addresses. Doing so
would have significant privacy downsides, would enable
new methods for censorship and discrimination, and could
be very hard to mitigate should one wish to help protect
people's privacy, as I think is current IETF policy.
If the work precluded the use of any identifiers that
strongly map to humans then I'd be ok with it being done
as it'd then only be a waste of resources. But I don't
know how that could be enforced so I think it'd be better
to just not do this work at all.
S.
+1
I know how to restrict the work to 'meaningless' identifiers, require that the identifiers be the output of a cryptographic algorithm.
Now strictly speaking, this only limits scope to identifiers that are indexical as opposed to rendering them meaningless but I think that was the sense of it.
Nöth proposed a trichotemy of identifiers as follows
* Identity, the signifier is the signified (e.g. data: URI)
* Indexical, the signifier is related to the signified by a systematic relationship, (e.g. ni URIs, SHA256Data), PGP fingerprints etc.)
* Names, the signifier is the related to the signified by a purely conventional relationship, (e.g. example.com to its owner)
There is a big difference between attempting to manage indexical signifiers and names. Especially when the people trying to do so refuse to read any of the literature on semiotics.
Names are problematic because the only way that a conventional relationship can be implemented is through some sort of registration infrastructure and we already have one of those and the industry that manages it has a marketcap in the tens of billions.
Identifiers do lead to tractable solutions. But, this proposal looks a bit unfocused for IRTF consideration, an IETF WG? Really?
I wrote this for the ename workshop and I think it shows that some of the goals stated can be solved:
But this is what my names look like:
alice@xxxxxxxxxxxxxx--mb2gk-6duf5-ygyyl-jny5e-rwshz
They are both legal addresses fully compliant with the DNS etc specs. The first won't resolve on the regular DNS, the second does but the embedded security properties will only be enforced if the resolver understands the mm-- prefix.
I can use these names to achieve content based routing of both static and dynamic data. In the first case, the identifier is the fingerprint of the content itself, in the second, the identifier is the fingerprint of a key signing the content.