Clarification on how 3P can know if the user is trusted

[vachadave2]

When publisher receives an SRR, How does the publisher(who is not issuer) verify that the user is trusted by issuer (i.e. the encoded bit is set to trusted = true)? Would the user know whether they are trusted or not by the Issuer? Is there an expectation of an out of band (i.e. not covered by trust token API) mechanism by which the publisher obtains this 1 bit of information from the issuer?

[dvorak42]

With the caveat that we're planning on making an update to make the SRR completely issuer-specified and rename it to be a Redemtion Record.

In the current version with a well-specified SRR, 3P are expected to have communicated with the issuer out of band to get the SRR key, meaning of the various public metadata values, and some method of decoding the private metadata (either an endpoint to query or the key material to decode it, though the issuer would likely only make this available to certain 3Ps it has a relationship with, otherwise this is just a private metadata oracle).

In the version where the SRR is just a generic Redemption Record and issuer-specified, we expect different ecosystems to come up with their own standard encoding for the Redemption Record and means of distributing verification key material.

[vachadave2]

Thanks for quick clarification. A few more questions:

1. Are you planning to add additional details on making the SRR issuer-specified? I am interpreting this to mean that the Issuer can choose SRR structure to contain more or less details than what is currently provided - is that accurate?
2. Is there a plan to release some sample redemption record structures along with the security/privacy guarantees they may provide?
3. In this new scenario, what is the way to verify the amount of information being passed from issuer to redeemer?

[dvorak42]

1) We'll update the explainer shortly, but yes it means the issuer can just but whatever information they want into the RedemptionRecord and then that's sent as part of the send-(s)rr fetch request.

2) We might move the existing redemption record structure into an appendix as a sample. For the security/privacy guarantees we'll provide the guarantees that an arbitrary redemption record provides, rather than what specific structures provide, since for the client the privacy considerations are identical (it provides the same properties as an arbitrary non-trust token fetch returning data that is then included in subsequent requests in the same top-level context).

3) This is the main reason we are changing this to be generalized, in that in the existing web model, there is no way to limit the amount of information being passed by the issuer to the redeemer at redemption time (while fixing the SRR prevented that request from containing additional data, the redeemer can just make a second non-Trust Token request right after to get the 'additional information').

[tgr]

That would mean every issuer has to come up with their own method of making the redemption record cryptographically verifiable (since the publisher receives the record from the user, it needs to be unforgeable and have some kind of double-spend protection), so a standard library for publishers accepting trust tokens won't be possible and issuers need to provide their own libraries. It seems to me like that could significantly hamper adoption.

[dvorak42]

We expect different ecosystems of issuers would standardize their own formats for redemption records, and use cases where the redemption record is self-contained and self-verifiable could embed some sort of signature, others would have the redemption record just be a generated ID, that the publisher would then query the issuer to ask it to verify that the record corresponds to a 'good' token, etc.