Explore Storing Tokens as a Custom Post Type instead of User Meta

Prompted by @pfefferle, and something I'd considered in the past. The biggest issue is migration, but I'd deliberately built into the plugin a class the token storage classes are all inherited from. There are currently two...one that stores as a transient, the other as user meta. I would just have to improve that abstraction a bit.

The advantage of the current system is its simplicity, but things have gotten more complicated since I did it. So, proposal is as follows.

• Introduction of new custom post type to store tokens, mapping the following properties to post properties:
• 'me' - since this is a function of the author, it would be derived from the post_author property
• 'scope' - Could be stored in the excerpt or content
• 'client_id' - Proposed client data be stored as a taxonomy attached here, which could also be attached to posts in micropub
• We have 3 time properties...
• 'iat' - When the token was issued, which usually maps to published as an equivalent
• 'exp' - When the token expires(which is optional), not sure where to store this...I suppose meta is the best place, as the expiry dates of all tokens could be picked up in a single query, but...
• 'last_accessed' - which is when the token was last used and could reflect modified
• 'last_ip' - We also store the last IP address.
• 'uuid' - Never used this, but wanted a way to uniquely identify a token...so this could be replaced with post_id.

Start by reading the existing token storage abstraction and its transient and user-meta implementations. Review the proposed custom post type field mappings, including migration, expiry, IP, and client data storage. Done would require an agreed storage design and a migration path before implementation can begin.