View source for Sender Constrained Token

==Full Title or Meme==
A [[Sender Constrained Token]] can be considered to be a token there the [[Subject]] presenting the token can prove possession of some credential that is bound to the token.
==Context==
* In common [[OpenID Connect]] code flows, the response to the user's consent is used by the relying party (confusingly called the user's client) to request an access_token (which is typically a [[Bearer Token]]) and a refresh_token (which is typically a [[Sender Constrained Token]].

==Problems==
* [[Bearer Token]]s have proven to be susceptible to reuse by unauthorized parties.
* The most commonly accessed protected resource is [[User Private Information]], which has had low value in the view of the web sites heretofore.
* On 2019-12-09, 1 & 1 Telecommunications was fined €9.55 million ($10.6 million) by Germany's Federal Commissioner for Data Protection and Freedom of Information, or BfDI, for its failure to put in place "sufficient technical and organizational measures" to protect customer data in its call center environments.<ref>Matthew Schwartz, ''GDPR Violation: German Privacy Regulator Fines 1&1 Telecom'' (2019-12-09) Bank Info Security. https://www.bankinfosecurity.com/gdpr-breach-german-privacy-regulator-fines-11-telecom-a-13482</ref> Perhaps it is time to increase security of user data?

==Solutions==
* Add a cryptographic binding between the token a some credential that is known to be in the secured possession of the [[Subject]]]
* For any scenario where the protect resource has high value, a [[Sender Constrained Token]] is the more secure solution.
==References==

[[Category:Glossary]]
[[Category:Authorization]]