Re: [Spud] Whats missing in SPUD

[Daniel Kahn Gillmor <[e-mail]>]

On Mon 2015-08-10 17:06:18 -0400, Toerless Eckert wrote:
> Well, biostats/signature/photo constitute elements to establish
> ownership of the ID card. And there may be county/city police
> regulations to keep track of full ID scans. And if not police then
> insurance or on advice of the bars lawyer in case of
> lawsuits/challenges. Aka: IMHO much more likely caused by third party
> directives then lets say the customer data collection done by eg:
> web/social-networking sites.

Sure.  So should we design a protocol that facilitates the publication
and collection of arbitrary data that might be of interest to any
regulator/lawyer/advertiser/insurer (or criminal/spy/competitor/troll)
able to influence any device along the path?

I share your concern about the customer data collection done by
web/social-networking sites, which today are indistinguishable from "the
network" for many users.  But the remedy for this is not to help make
the lower layers of the network (i.e. IETF purview) as bad for user
privacy as the worst of the centralized services are.

> But lets agree that the ID card in its current form is not ideal to
> exemplify "know what attributes you need to show for the desired benefits
> and then only show those attributes".

That's why we're having this discussion -- because we do not want to
produce a network transport protocol with sufficient flexibility and
power to implement the "show your full identity to an arbitrary
intermediary order to be able to socialize" antipattern, even though i'm
sure some arbitrary intermediaries would love such a thing.

> So the right example would have been some form of ID card with keypad,
> i type in what attributes i want to send, it creates a new short lived
> cert and NFC's those attributes to the gatekeeper. Whether its Photo +
> (Age > 17) or anything else.

We're not designing a beer-delivery protocol layer (though that does
sound like more fun), we're designing a network transport layer.  It
should be designed for transporting data through the network, not for
facilitation of arbitrary interference by any network operator.

Can you reframe your proposal in the network transport layer context in
a way that seems feasible to implement, is comprehensible to the user,
doesn't encourage the false-tradeoff antipattern, and is actually
effective at improving user experience on the network (as compared to,
say, spending the same amount of engineering effort on a faster link
layer)?

All the best,

        --dkg