Re: [Privacy-pass] Privacy Pass draft comments

[Steven Valdez <[e-mail]>]

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.

(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?)

---

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.

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