Month: October 2023

On many occasions in the past, I’ve participated in private post discussions as part of various Indiewebcamp events.

Private resources…posts, feeds, or any sort of private content, is one of the holy grails of the Indieweb community. Everyone seems to want it, but we haven’t made that much progress on a simple solution.

In order to enable the ability for an arbitrary person to get access to private resources  we need to give them some sort of credential to do so.

There were multiple proposals…Private Webmentions, AutoAuth…etc floated. Most recently, in 2020, we started talking about Ticket Auth….which we just renamed Ticketing for IndieAuth.

The rename is because the proposal is an extension to IndieAuth, it isn’t an authentication system by itself. None of the previous efforts clicked with me. They seemed to be…too much. The joy I have with of Indieweb protocols is how easy they are. That is a credit to how the community has developed and written them.

The concept of ticketing, which is the same concept used in Private Webmentions in 2016, is that the publisher is the one initiating the interaction. AutoAuth, by comparison, starts the flow with the consumer requesting access.

A ticket is an invitation in the form of a code that the consumer can redeem for a token, the same way a ticket to an amusement park is redeemed for entry.

The problem with requesting access is that it assumes the consumer knows about the private resource…which by itself could be leaking information the publisher doesn’t want to know.

So, that means the first step for our proposal has to be that it does not require the resource to advertise itself. That doesn’t mean it can’t…it means that requirement isn’t built into the protocol.

So, as the story goes, our publisher…let’s call him Zeke, wants to let Yoshi access Zeke’s private resource…let’s say a private feed. Why? Who cares? Zeke does.

So Zeke polls Yoshi’s website and sees he advertises a ticket endpoint as part of his IndieAuth configuration. A ticket endpoint indicates to Zeke that Yoshi is set up to receive tickets and redeem them for tokens. So, Zeke sends Yoshi a ticket.

Yoshi’s ticket endpoint receives the ticket, and redeems it for a token from Zeke’s token endpoint(the thing that issues tokens for Zeke). Now, what Yoshi does with the token isn’t in the protocol, that’s Yoshi’s business. Yoshi can integrate the ticket endpoint with a reader that will retrieve the content for Yoshi to read, or whatever.

In my opinion, that’s all this extension is meant to be. and there are some rough edges about that exchange we have to smooth. But it is simple, it works…

I differ with another community member on this, who wrote this draft version of an IndieAuth Ticketing specification because, if I understand correctly, while I think not defining all the parts he needed for his dream implementation within this specific protocol was a strength, he considers it a weakness.

This includes the original ticket endpoint, which he refers to as the ‘ticket deposit’ flow. And the redeeming of that ticket, which he calls the ‘ticket grant’ flow. But it adds additional pieces…

First is the ‘ticket wanted’ flow, which creates another endpoint for a user to request a ticket. Now, this is something we did discuss as a possible optional piece that could be implemented to indicate to a publisher you wanted a token. But is it a necessary component for this concept? If we do put in a flow like this, it should be truly optional to implement.

Second is the ‘authorization code on-behalf-of’ flow. This flow is an attempt to solve a different problem, which I’m saying is also out of band for Ticketing. It is how you can request a token on behalf of someone else. This flow seems to be based on RFC8693.

It seems complicated to me because it relies on the reader/client asking Yoshi to request a ticket from Zeke(using that ticket wanted flow), and then getting the ticket and using it.

The question that seems more within the scope of the Ticketing extension is…if your ticket endpoint can redeem a token, how would you pass it to a client or reader to use? We started with the assumption the ticket endpoint would do the redemption.

I think there is certainly a bigger discussion about this to be had…token delegation. I think there may be other solutions that might work with the goal of a simplified flow. As it stands, assuming the token is used by a tightly coupled endpoint, how the token is used can be out of band for now.

For me, right now, I’m focused on sending of a ticket and its subsequent redemption and sorting out a few lingering questions about that, and then I’d can implement simple token exchanges with others and iterate on that.

What do everyone think?