Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP usage is ... #229

Open
martinthomson opened this issue Apr 1, 2023 · 4 comments
Open

HTTP usage is ... #229

martinthomson opened this issue Apr 1, 2023 · 4 comments
Labels

Comments

@martinthomson
Copy link

martinthomson commented Apr 1, 2023

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.

@miketaylr

This comment was marked as outdated.

@dvorak42
Copy link
Collaborator

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.

@martinthomson
Copy link
Author

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.

@dvorak42
Copy link
Collaborator

Oops, missed that that got picked into the spec. That shouldn't be there. I'll make a commit to remove it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants