Private State Token Issuer Request - AUTHFY
Closed this issue · 13 comments
Issuer Name
AUTHFY
Origin
Contact Email
Key Commitment Endpoint URL
https://pst.authfy.tech/.well-known/trust-token/key-commitment
Purpose
Authfy is an Anti-Fraud product developed by SEC4YOU (https://www.sec4u.com.br), we want to deliver to our clients the capability to use PST technology in order to prevent fraud and improve customer experience.
Disclosure and Acknowledgement
- I understand the technical restrictions on key rotation frequency of 60 days in the PST API.
- I understand that my issuer registration will be valid for a period of six months after the key commitment is accepted, and that I will need to re-register in this repository following that six-month period.
- I understand that in the future renewing my registration for this API may have additional requirements, to reduce the risk of abuse by token issuers.
It appears your expriy format is incorrect, you should have the expiry as a JSON string, rather than a number.
We've fixed the format for the expiry entry, i should close this issue and open a new one?
(Just updating this issue as you make fixes is fine, you don't need to open a new issue)
It looks like you're adding a "charset" parameter as part of the Content-Type for the key commitment, which is only valid for "text/" content types.
If its difficult to remove the charset parameter, we can see about removing that enforcement for the parser, but we won't likely be able to do that until the new year, if you can remove it from the content type on the endpoint, that might be the fastest way to resolve.
you mean the: ; charset=utf-8, don't worry, you can keep the enforcement, we will manage to remove this guy from the header, i'll let you know when its done.
@dvorak42, done i've tested with curl -v and the ; charset=utf-8 is gone. let me know if anything else is missing or need to be adjusted.
Sorry, missed checking it the first time. It looks like your "id" and "batchsize" fields are currently strings, while they should be integers (you'll need to get rid of the quotes for those two fields in the top-level dictionary).
But the spec on the URL https://wicg.github.io/trust-token-api/ states that:
"batchsize" specifies the maximum number of masked tokens that the issuer supports for each token issuance operation. Its value is a string representation of a positive integer.
"id" field provides the identifier of the key commitment. It is a string representation of a non-negative integer that is within the range of an unsigned 32 bit integer type. Values should be montonically increasing.
Apologies in advance if my understanding was wrong.
Let me know if i should proceed the change to integer or continue as string, i just wanted to do a "double-check" if our implementation is correct.
Unfortunately I believe this is a bug that cropped up when we converted the design document/explainer into a spec document.
The correct behavior is that those two fields should be integers, I've filed WICG/trust-token-api#279 to track fixing the spec issue.
Thanks, i've checked the PR WICG/trust-token-api#280 opened by aykutbulut with the fix of the 2 fields definition, our key-commitment endpoint has already been updated with the change to integer @dvorak42
@dvorak42 the server has been updated with the fix, let me know if anything else is missing.
Hi, everything looks good. However with the holidays, the PR (#19) to merge in your issuer may not get reviewed and imported until Tuesday.
Your keys have been successfully parsed, they should be available in Chrome via component updater in approximately 4 hours (you can force an update by going to chrome://components/ and hitting "Check for update" under Trust Token Key Commitments).