4 ms·

So, like, give unique IDs to things and then move them around?

xyzzy123 5y ago
The most useful kinds of tokenization will "anchor" the data to a specific platform, and allow you to perform common operations without slinging plaintext around. So it's a token and an interface, where the minimum interface is "give me the plaintext back", but richer interfaces are possible and more useful. So e.g. once you tokenize a card, you can perform billing operations on the token. The original CHD is "too liquid" and can be used anywhere in the financial system. If the token platform ensures only you can get paid with the token that can the limit the scope of badness. You can also apply auditing and enforce extra access control / policy around operations or exchange of tokens for plaintext. In a complex system this can be better than letting sensitive information propagate to different data stores or business units. It also means you can build out the auditing & controls just once instead of needing controls in N systems. It's also a decent tactic for "compliance engineering" in terms of being able to draw a box around which parts of the system you expect your auditor(s) to want to look at really closely. Things can rapidly get expensive when too much stuff comes into audit scope.
- jamesarmstead 5y ago
  I love this description and the concept of “compliance engineering”!
smegsicle 5y ago
an analogy i like is that if encryption is a locked box you're passing around, using a token is like passing around a safe deposit box key instead- the real secret is still secure at the bank, probably encrypted as if by a teller's key (not with your token-"key", which is not an encryption key, just a reference to the box, and you can make as many tokens to the same box as you want.. so that's a rough edge to the analogy) but anyway, it's just passing references around, so i think the main reason it gets confusing is because it's discussed as an alternative to encryption, despite being kind of the opposite of encryption (passing around a token and protecting the vault, vs passing around ciphertext and protecting the key)
- jamesarmstead 5y ago
  Bingo! The underlying value is stored safely away from the systems passing around the reference - this makes it simpler and safer for the underlying systems to use the plaintext vs needing to share the private key with each system needing to touch the data!
- drewcoo 5y ago
  I thought they were talking about something more like canonicalizing and hashing the data.
  - smegsicle 5y ago
    generally tokens are arbitrary codes without any mathematical relationship to the data, so that a token being leaked doesn't reveal anything about the secret (you might want to invalidate leaked tokens tho)

The most useful kinds of tokenization will "anchor" the data to a specific platform, and allow you to perform common operations without slinging plaintext around. So it's a token and an interface, where the minimum interface is "give me the plaintext back", but richer interfaces are possible and more useful. So e.g. once you tokenize a card, you can perform billing operations on the token. The original CHD is "too liquid" and can be used anywhere in the financial system. If the token platform ensures only you can get paid with the token that can the limit the scope of badness. You can also apply auditing and enforce extra access control / policy around operations or exchange of tokens for plaintext. In a complex system this can be better than letting sensitive information propagate to different data stores or business units. It also means you can build out the auditing & controls just once instead of needing controls in N systems. It's also a decent tactic for "compliance engineering" in terms of being able to draw a box around which parts of the system you expect your auditor(s) to want to look at really closely. Things can rapidly get expensive when too much stuff comes into audit scope.

jamesarmstead 5y ago
I love this description and the concept of “compliance engineering”!

smegsicle 5y ago

an analogy i like is that if encryption is a locked box you're passing around, using a token is like passing around a safe deposit box key instead- the real secret is still secure at the bank, probably encrypted as if by a teller's key (not with your token-"key", which is not an encryption key, just a reference to the box, and you can make as many tokens to the same box as you want.. so that's a rough edge to the analogy) but anyway, it's just passing references around, so i think the main reason it gets confusing is because it's discussed as an alternative to encryption, despite being kind of the opposite of encryption (passing around a token and protecting the vault, vs passing around ciphertext and protecting the key)

jamesarmstead 5y ago
Bingo! The underlying value is stored safely away from the systems passing around the reference - this makes it simpler and safer for the underlying systems to use the plaintext vs needing to share the private key with each system needing to touch the data!
drewcoo 5y ago
I thought they were talking about something more like canonicalizing and hashing the data.
- smegsicle 5y ago
  generally tokens are arbitrary codes without any mathematical relationship to the data, so that a token being leaked doesn't reveal anything about the secret (you might want to invalidate leaked tokens tho)