Using JWT for signature

[RomainLofaso]

It is already a few weeks that we consider JWT. Here are a few arguments:

1. JWT can handle both signature and encryption - if we consider later the need for encryption.
2. It has an RFC and thus is a standard of the web.

JWT can be used in different ways in our solutions. It can:

1. Secure the redirections including Publishers, Operators, and User Interface Providers against URL replay.
2. Potentially secure the read of cookies thanks to encryption.
3. Sign the Prebid SSO Data for the accountability of the Contracting Party that generated it.
4. Sign the Transmission Request for trusting the sender.

Each point must be challenged. Ideally, we would like to use JWT for all of them by simplicity and consistency but we are worried about twisting the solution and getting a not flexible architecture due to a tool (the cognitive bias of the Hammer Law).

[jwrosewell]

FWIW Here's why JWT were not used in SWAN.

[RomainLofaso]

Thank you. If we quote the OWID document:

JSON Web Tokens

OWID was inspired by JWT and adopted some similar conventions and names such as payload and signature.

JWT were considered as a basis for OWIDs but do not meet all the design goals. Specifically, JWT provides flexibility concerning a choice of algorithm and uses JSON for data storage. JSON as a data structure is less efficient than binary data structures. Using a single algorithm reduces implementation complexity.

Agree on the efficiency of a binary format compared to JWT. However, the implementation of JWT can be less complex because it is a standard: most of the programming languages have a library that encapsulates the complexity of JWT for you and you may have already used it (i.e you are already at the top of the learning curve).

We consider JWT because it addresses the signature, the encryption, and the communications in a standard way. However, some blocking points are:

1. JWT signs only the header and the payload. AFAIK, we cannot have a reference to something outside of the JWT. So Preferences and Transmission signed with a JWT have duplicated data (respectively ID and Seed). It is really not network/space-efficient. The problem is orthogonal to the JSON format. It is structural.
2. JWT (and OWID) is attached to a defined format. The OpenRTB protocol doesn't. It highlights JSON but you can optionally implement it in other formats. For a great integration of Prebid SSO, it can be interesting to have the same characteristic. The only fixed format should be in the cookies of the top-level domain of the Operators.
3. If we use JWT only to protect again the URL replay and we use another format/protocol (e.g OWID) for the signature then it can complexity the solution

For now, the design solution provides "source" metadata instead of OWID or JWT. The pros are:

1. It is metadata and not an envelope so it is flexible.
2. It contains always the same metadata as OWID.
3. It can be in different formats (JSON, protobuf...).

The cons are:

1. It is not standardized.
2. Like OWID, you still need to check the documentation to rebuild the signed values (you don't with JWT). The advantage over OWID is that it is at least explicit and clear: on its side, an OWID is considered as an envelope but with potential tacit references to other OWIDs.

[jwrosewell]

We should also consider the benefits and draw backs of PEM (and the like) for certificates and keys where the data is similarly immutable. How important is human inspection without a library to perform the transformation versus reducing bytes?

Like certificates a defined and prescriptive format helps eliminate defects and interoperability issues. It is either bit level correct, or not. Testing is simple and performed against a defined bit level format.

Overall, as soon as there are more OR branches then the complexity increases. Therefore as a policy do we value flexibility of implementation in the future over reducing complexity for the majority of implementers today?

[OlivierChirouze]

I like the way you put it, James:

How important is human inspection without a library to perform the transformation versus reducing bytes? I think this is a key question. Maybe reducing bytes while providing online tools to inspect data is a good happy middle?

However, I'm not sure to follow what you refer to when saying:

Overall, as soon as there are more OR branches then the complexity increases I understand the debate is around flexibility, but I'm not sure exactly what we are comparing (sorry 😊) Is it about the algorithm used by JWT? Can we not propose to use JWT, but forcing the encryption scheme that is supported?

As for the general discussion on a real "envelope" that includes data and signature, I think it's worth it to challenge a solution (JWT, OWID or other), where all data is present in the payload that is signed. After more thinking, I believe the only change that it would require is:

• store prebid_id signature with preferences
• store seed signature with each transmission It has a cost (and clearly goes against the objective to "save bytes"), but if we value more the standardisation of the solution, I think it is not a big additional cost.

I think reducing the general "weight" of the solution is a topic on its own (where timestamp is part of the question, but also using short names if we use JSON, for example). WDYT about creating a dedicated issue for it?

[jwrosewell]

Regarding my more "OR" branches comment. "You can have any colour you want as long as its black" - Henry Ford. The point being that the fewer options there are the easier it is to understand. It's a general principle where I think the project should be seeking to focus on a tight and defined deployed that reduces risk of mistakes or divergence. This is important given the industry has a lot to deal with and isn't historically great at all doing the same thing at once. Therefore this is a principle for the project first and foremost. I don't think we've set out those principles yet.

I'm still reading into the work here. I'd need to understand the wider set of different IDs, where they come from, and their relationship with the Model Terms.

[OlivierChirouze]

Thanks, I get the point. I agree there should be a clear project direction if we target high flexibility or, to the opposite, a single and strongly defined option. I'll let other people from the Prebid committees take position.