Subject: [Privacy-pass] Why HTTP authentication?

From: Watson Ladd <[email-masked]>
Date: Wed, 2 Feb 2022 18:00:52 -0500

Dear Privacy Pass,

I'm wondering why we are looking at HTTP authentication as a means for
obtaining and redeeming tokens. Previous iterations have been able to
use javascript for implementation as redemption was triggered via the
body of HTTP requests.

By contrast a new HTTP authentication scheme will likely require some
more extension for Javascript to access. This seems to have been
discussed in the interim but I'm having trouble reconstructing from
the minutes.

Sincerely,
Watson Ladd
-- 
Astra mortemque praestare gradatim

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 02 Feb 2022 16:01:06 -0800

Hi Watson,

There are a few reasons, as discussed at the interim:

- There are use cases for redeeming tokens that aren’t just in Javascript contexts. For example, we already use these blinded tokens in our iCloud Private Relay auth, and we’re also aware of many app-based use cases that would like to use a privacy pass mechanism without being strictly a browser.
- HTTP auth allows us to have multiple types in a challenge to help communicate which types of tokens and which token issuers are supported, in a common fashion. This also works well for supporting new types of tokens.
- Having HTTP auth doesn’t preclude Javascript from driving the privacy pass exchange — or honestly doing its own thing if it wants.
- This also allows privacy pass as an IETF standard to have a complete package that can be used without dependencies on other specs.

Steven can comment on the changes required for the Javascript layer to drive the HTTP auth mechanism, but he believes it should be a relatively clean fit.

Best,
Tommy

> On Feb 2, 2022, at 3:00 PM, Watson Ladd <[email-masked]> wrote:
> 
> Dear Privacy Pass,
> 
> Privacy-pass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacy-pass

---

From: Steven Valdez <[email-masked]>
Date: Thu, 3 Feb 2022 10:41:13 -0500

Generally I think the Javascript API built on top of the HTTP Auth change
should be fairly straightforward, with the JS constructing an equivalent
Token Challenge struct to that in the WWW-Authenticate header, and sending
that to the mediator as part of issuance/redemption. Its more
straight-forward for the non-interactive case since the JS at issuance time
can just apriori generate challenges to get tokens issued, but as long as
the site feeds in the nonce to the JS for interactive tokens if they're not
using HTTP-Auth, it should still be minimal changes to the API surface.

The one complication might be about how to send the Token back to the
server if not through the Authorization header (if endpoints/LBs are doing
special handling of that and a server still wants to use the JS API without
that), but having the Javascript API define a way of including the
Authorization payload elsewhere shouldn't be too bad (currently we have a
bespoke "Trust-Token" header in the Trust Token JS API).

On Wed, Feb 2, 2022 at 7:01 PM Tommy Pauly <[email-masked]> wrote:

> - There are use cases for redeeming tokens that aren’t just in Javascript
> contexts. For example, we already use these blinded tokens in our iCloud
> Private Relay auth, and we’re also aware of many app-based use cases that
> would like to use a privacy pass mechanism without being strictly a browser.
> - HTTP auth allows us to have multiple types in a challenge to help
> communicate which types of tokens and which token issuers are supported, in
> a common fashion. This also works well for supporting new types of tokens.
> - Having HTTP auth doesn’t preclude Javascript from driving the privacy
> pass exchange — or honestly doing its own thing if it wants.
> - This also allows privacy pass as an IETF standard to have a complete
> package that can be used without dependencies on other specs.
>
> Steven can comment on the changes required for the Javascript layer to
> drive the HTTP auth mechanism, but he believes it should be a relatively
> clean fit.
>
> Best,
> Tommy
>

-- 

 Steven Valdez |  Chrome Privacy Sandbox |  [email-masked] |  Cambridge,
MA

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 8 Feb 2022 16:22:40 +0800

Steven Valdez <svaldez=[email-masked]> 于2022年2月3日周四 23:41写道：

> +1
Personally I think, the nonce can get from JS, through some restful api.
The tokens could send through JS payload or HTTP auth, depends on the
website's use case.