HTTP usage is ...
martinthomson opened this issue · 4 comments
The HTTP interface described in this specification is unusual.
A more typical issuance flow would involve the passing of inputs in the content of message, describing the format with media types. The content of the response would include the response, again identified with a media type. A similar exchange might be used for redemption.
The current approach decorates a request with header fields. It appears as though that request could be made to any resource and for any purpose, meaning that it could serve a dual purpose. This is especially odd.
In addition to header fields, there also appears to be some notion that the request will have query parameters appended, with public or private data being passed in predefined parameters. This is totally unnecessary, as the site has complete control over the URL and can encode that information - or much more - as a result.
See also #221.
(I was going to use another word here, but this is the least pejorative word I could muster).
You could delete this parenthetical and not distract from your larger point on design. Folks who aren't personally familiar with your wit might think you're trying to be condescending. :)
We've debated moving to something closer to privacypass for the issuance/redemption responses where there are specific requests/responses for these operations, however based on Origin Trial feedback and discussions with CAPTCHA/Anti-fraud providers, there is a substantial increase in functionality/ergonomics to be able to combine issuance/redemption requests with existing requests made to the provider servers (ie including a CAPTCHA challenge solution as part of the issuance request or a CAPTCHA request as part of a redemption response) compared to having to keep track of the additional state to bind the issuance/redemption request with the other data that a provider might need to make the issuance/redemption decisions. There's also some concern about latency (for providers that aren't relying on H2/H3 streams).
As the API gets standardized and the ecosystem usage of this API matures, we can hopefully either support both the standard non-header version of this API and potentially eventually deprecate the header version if usage is low enough or there's enough developer tooling/support for standard ways of correlating issuance/redemption requests with other data.
Where are you seeing the query parameters? We have it in the trusttoken.dev demo just as a easy way to get different tokens issued, but I don't believe that is specified/standardized anywhere, if it is we should make sure to tag it as an example for dev experimentation and not a recommendation on how production issuers should act.
This question is somewhat moot if you look at #221, which is definitely my preference. Then "standard" isn't something we need to consider.
To answer the question about query parameters, Section 6.2 says:
Information to be encoded in the tokens are passed in the URL public and private parameters.
Oops, missed that that got picked into the spec. That shouldn't be there. I'll make a commit to remove it.