search

WICG / trust-token-api

Trust Token API
https://wicg.github.io/trust-token-api/
Other
419 stars 84 forks source link

Should the dictionary in https://wicg.github.io/trust-token-api/#issuer-public-keys be defined in webidl? #206

Closed miketaylr closed 1 year ago

miketaylr commented 1 year ago

Because this is returned by the server, I'm not super sure - but it would seem nicer and more understandable to define the interface and types, then define each dictionary member. Thoughts @johannhof?

Another question I have is "Requests to key commitment endpoints should result in a JSON response [RFC8259] of the following format" - is this the return value of an algorithm defined here?

Maybe WebSockets is a model for this server/client integration piece, not really sure.

miketaylr commented 1 year ago

cc @aykutbulut @dvorak42 in case they have the answers!

aykutbulut commented 1 year ago

Issuer key commitments are obtained through periodic component updater runs. Do we use webidl for component updater side as well? Or a similar mechanism specific to component updater?

miketaylr commented 1 year ago

Issuer key commitments are obtained through periodic component updater runs.

OK - that's useful information! Component updater is a Chromium-specific concept, so we don't want to encode that in the spec. I do think we probably want some kind of more formalized way to say "this is the format and types of Issuer key commitments, however you get them." But let's see what @johannhof thinks.

johannhof commented 1 year ago

I didn't know about this issue when I made the suggestion but https://github.com/WICG/trust-token-api/pull/207#discussion_r1119444546 should be what you want? i.e. define key commitments to be a map as it's directly parsed from JSON? We could also make it a struct with defined fields which would make the spec much nicer to read in some places, but come with the extra conversion effort :)

miketaylr commented 1 year ago

Yep, I think that would help a lot. Let's punt on the extra effort bit - it can be follow-up work. I'm going to close here in favor of your comment, thanks!