Re: [Privacy-pass] Privacy Pass draft comments

[Ben Schwartz <[e-mail]>]

On Fri, Jul 24, 2020 at 6:04 PM Steven Valdez <svaldez=
[e-mail]> wrote:

> In terms of the bit of metadata, in the current drafts it's not currently
> tied to a specific proposal and doesn't have a protocol to support it, but
> one potential way to support it is building on top of the PMBToken
> primitive which provides the one bit of metadata property. Unless I'm
> looking at the wrong section, it currently uses a bit of metadata as an
> example of the privacy considerations that metadata introduces.
>

I'm referring to Section 9.1:

>   In terms of additional metadata, the only concrete applications of
>   Privacy Pass that use additional metadata require just a single bit.

There's no mention of what concrete applications these might be.

(As for the specific PMBToken case, it lets an issuer set a token to be one
> of two values, that are both cryptographically signed. I think the one
> you're looking at is the other construction for a PrivacyPass token without
> the ZKPs?)
>

Thanks, I was looking at an intermediate construction in the PMB paper.


>
> ---
>
> For the HTTP API, one open question (short list in the presentation for
> 108), includes whether the API recommended in the WG document should be
> tied to .well-known endpoints or if we should generalize it to allow the
> issuer to provide the capabilities on top of any endpoint. But yes, the
> current draft has a foot in both worlds, and once we resolve that question
> either moving it to a REST API on the well-known or omitting the well known
> entirely is probably the right move.
>

Sounds good.  I'm sure we can figure that out.


>
> Keeping it at .well-known would mean doing something like:
>
> https://captcha.example/submit-challenge-answer (sets state with the
> result of the challenge).
> https://captcha.example/.well-known/privacy-pass (Does the actual
> issuance via PrivacyPass)
>
> Potentially a server might want something like:
>
> https://captcha.example/submit-challenge-answer and if the client
> attaches an issuance request in the Sec-Privacy-Pass header, the response
> could return PrivacyPass tokens directly.
>
> On Fri, Jul 24, 2020 at 5:43 PM Ben Schwartz <bemasc=
> [e-mail]> wrote:
>
>> Some comments on the drafts scheduled for discussion in our session next
>> week:
>>
>> On the architecture:
>> The draft mentions a use case for "1 bit of metadata" without further
>> explanation.  Is this in reference to the PMBToken proposal?  I think it
>> would be worth clarifying the reference..
>>
>> Regarding PMBToken, I'm not sure that proposal necessarily reduces the
>> anonymity set in the way that the architecture draft describes.  It sounds
>> like the server returns either a valid token, which the server can later
>> verify, or an invalid token, which the server cannot distinguish from
>> client-generated garbage.  If so, we might avoid reduction of client
>> anonymity by encouraging all clients to attempt to send garbage tokens
>> occasionally.  "Don't Take Any Wooden Nickels" [1].
>>
>> On the HTTP API:
>> There's no explanation of why this is all being jammed into a
>> Sec-Privacy-Pass header.  This is very much unlike a typical REST API.
>> What's the goal here?  I think it would be worth clarifying.
>>
>> If this design is to allow tacking redemptions onto arbitrary HTTP
>> requests like a cookie, then could issuance still be a normal REST API?
>> Then we probably wouldn't need the "type" field for redemption; it could be
>> implicit.
>>
>> --Ben
>>
>> [1] https://en.wiktionary.org/wiki/don%27t_take_any_wooden_nickels
>> --
>> Privacy-pass mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>
>
>
> --
>
> Steven Valdez |  Chrome Privacy Sandbox |  [e-mail] |
> 210-692-4742 <(210)%20692-4742>
>