Thinking about Ticket Auth

During this month’s Pop-Up event, as part of the overall topic of sensitive data we were discussing the continual challenges in getting a method of having private posts on one’s site. As a community, nothing has gained enough traction for adoption.

Last summer, a conversation on the most promising at the time, AutoAuth, prompted a new contender Ticket Auth. Ticket Auth turns the relationship in the other direction.

Let’s use our favorite two example people, Alice and Bob. Alice has a post on her site which she doesn’t want to be public. For most sites, the default is public. Alice wants to share her post only with Bob.

AutoAuth doesn’t get into the idea of how Bob, or the client Bob is using, decides he wants to get access to Alice’s post. Ticket Auth, by comparison, puts the onus on Alice. Alice, when she decides on her audience, sends a ticket to those she wants to have access. Bob has to have a ticket endpoint…the place he received tickets.

The ticket is a code that is available for a limited time, that can be exchanged for a longer term token to access the information. It is, essentially, an invitation you are free to accept or ignore.

In trying to develop more, this is a good place to start. Once we start sending and receiving tickets, we can iterate on this and figure out the next questions.

• Can you ask for a ticket and how?
• How can you give the ticket or the token you redeem to your reader or other client?

But first things first. Let’s build something.