Re: [Privacy-pass] Questions on client trust

[Ben Schwartz <[e-mail]>]

I don't understand what "is human" is supposed to mean.  Surely for this
protocol it is always false!  For clarity, I would not want this phrasing
in the charter.

I also don't understand how a transferable, anonymous, single-use token
asserts anything about the holder, or has anything to do with trust.  I
think we should adjust the phrasing there too.  I would prefer to have a
charter that speaks of acquiring and spending unlinkable tokens.

I think we should rule all content (blind signing) strictly out of scope.
The complexity of supporting content is not worth it for N<4 bits; just
encode the content in unary by the choice of issuer.  If that proves too
inefficient after this is all finished, we can consider a follow-on
specification with content.

On Tue, Apr 14, 2020 at 7:50 AM Alex Davidson <adavidson=
[e-mail]> wrote:

>
> > On 14 Apr 2020, at 03:43, Martin Thomson <[e-mail]> wrote:
> >
> > On Tue, Apr 7, 2020, at 04:57, Ben Schwartz wrote:
> >> On Thu, Apr 2, 2020 at 6:44 AM Alex Davidson
> >> <adavidson=[e-mail]> wrote:
> >>> - To what extent should client's trust the issuers when redeeming
> >>> tokens?
> >>> - Under what conditions should they accept/redeem tokens?
> >>> - What information does the client trust the issuer to encode in the
> >>> tokens?
> >>> - How does an ecosystem protect itself against issuer consolidation
> >>> and/or centralization?
> >>
> >> Since we are chartering, not designing, I think it's premature to try
> >> to solve these problems. At this stage, our goal should be to describe
> >> (1) the problems and (2) the scope of our ambition to address them.
> >
> > I think that this cuts to the core of the question of feasibility.  That
> is, is this a research project or an engineering task?
> >
> > There are two paths that avoid having to deal with these questions:
> >
> > 1. pick a single manifestation of the system, like "is human", build to
> that, and document this
> >
> > 2. make it very clear that the way in which the token conduit acts is
> very much subject to some amount of trust in the token issuer, explain that
> any carriage of token across what might otherwise be a privacy boundary
> requires that this trust exist, and build the system with that in mind
> >
> > The original charter might have been a shade more biased toward the
> latter approach, but the designs I saw included mechanisms that seemed to
> derive from a viewpoint that had less inherent reliance on trust.  The
> designs implied (at least to me) an assumption that the conduit didn't need
> to think or trust.  That might be possible for the "is human" bit in
> browsers, maybe, so that's not unreasonable.  That made this hard to assess
> because of those implicit assumptions.
>
> I would rather not scope as narrowly as “is human” as I think some of the
> proposed applications being considered are somewhat broader than that
> specific signal. I think the path that is raised in 2) is close to the
> direction that I was personally imagining that we would take. My preference
> would be to assume that the client has decided which
> Issuers/Registries/Vendors that it can trust and then build the protocol
> and architecture with this trust already established. There may be ways
> that we can provide broad recommendations on how clients may want to make
> this decision (e.g. based on the past behaviour of the Issuer in
> interactions, key rotations etc.) but going beyond that seems beyond the
> scope of the work, in my opinion.
>
> >> As often seems to be the case, I think we are not really talking about
> >> "more" or "less" consolidation, but rather trading off consolidation
> >> pressure in different elements of the ecosystem. The charter should
> >> acknowledge that some degree of consolidation pressure may be
> >> unavoidable, but we will do our best to minimize and mitigate it.
> >
> > This notion of how protocols act to shape market pressures is new for us
> here, so it might be OK to call it out as special.  We used to do that for
> security until it was sufficiently internalized.  However, we need to
> remember that this is just another factor we should each consider as we go
> through this process.  I don't want to over-rotate on consolidation when we
> also need to consider environmental impacts, the effect on underrepresented
> minority groups, accessibility, privacy, or any of a number of other
> important factors.
> >
> > The apparent need for trust of certain types in this system does tend to
> produce certain consolidation pressures that we need to acknowledge, but
> until we understand the precise role of trust, we can't know for sure.
> What is worse, the details of the information being conveyed likely has
> more of an effect on this than anything else, and it seems like there is a
> desire to make the information conveyed flexible.
> >
> > Maybe the consolidation thing is manageable for something like an "is
> human" assertion, but is completely intractable in the general case.  And
> maybe that is OK from a consolidation perspective because the protocol is
> completely unusable at global scale for any other sort of assertion.  And
> maybe that is terrible because it means the creation of islands of haves
> and have-nots for privacy pass.  (And maybe I should stop extrapolating
> from zero information.)
> >
>
> I think these are all valid things to consider regarding the issue of
> consolidation and its relationship with the trust dynamic between a client
> and the rest of the ecosystem. I agree with Ben that aiming to minimise
> this pressure in the design of the protocol architecture is something that
> we can commit to in the charter. We can then better establish in future
> documentation exactly how this mitigation would work, and how concerns of
> the nature that Martin has surfaced interplay with each other. I also agree
> that making a concrete assertion about the type of signals that the
> protocol can provide (“is human” or otherwise) is going to be essential in
> being able to answer these questions.
>
> Alex
>
> --
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>