Last Updated

I’ve been watching the situation in the Middle East, and stymied about what I should and want to say on the matter. Too many flashbacks to when I was in college, 20 years ago, and a series of articles in the college newspaper about the West Bank made the Letter to the Editor section of the paper grow to more than a page, when previously it was barely noticeable. I was one of the ones writing in opposition to the narrow view of the article, which claimed that because most Palestinians were significantly below the poverty line, they couldn’t buy weapons and therefore, were not doing what the Israelis accused them of doing. My opposition was pointing out that suggested that others were supplying them with weapons…and those same others were not helping in any other way.

I didn’t enjoy that tense period in my college career. And I’m starting to feel again what I did then…but this time, it is much much worse.  You watch the news and see the images of protesters in cities around the world, the significant rise in antisemitism, and you cannot help but be worried about the future.

Everyone is trying to take an incredibly complex problem and boil it down to a simple one…and spin it to look like what they want. That includes Hamas, the Israelis, the Arab world, and multiple groups around the world. I’m a centrist, and legitimately try to see both sides of an issue. But trying to see both sides of an issue does not mean that I’m going to rationalize away terrorism as legitimate resistance.

I can go through the history of the region. I can discuss the historical context of the issue if anyone wants to hear it.

But, let’s fast forward to the current year. Israel’s width is roughly 70 miles at its widest point and 6 at its shortest. It is roughly 260 miles long. It is slightly smaller in square mileage than New Jersey. So, imagine people in Delaware have a habit of shooting rockets into New Jersey.

So, it is a fact that Hamas has been smuggling weapons into Gaza. That they have learned to build their own locally using materials that can also be used for other purposes. If the choice is to let them do that, knowing where those weapons will be aimed at, we’re back to understanding Israel’s position on the matter.

It is the practical matter of what you’d expect Israel to do. And, this is not even talking about the more radical elements every country has. There are two territories that are in a position to lob rockets at your civilian population. Amongst the people who live there are terrorists who want to indiscriminately kill civilians and cause destruction. And the people there also want to come to your country to work because there are job opportunities there.

How do you solve this problem?  We’re back to…no good solution. Every option is equally bad. If Israel doesn’t destroy the Hamas infrastructure, it is an invitation for Hamas to rebuild and do this again. There is also the matter of over 200 hostages. If Israel continues to destroy the Hamas infrastructure, there will be casualties and destruction…because of where the Hamas infrastructure is…in some cases where they deliberately placed it in order to create this situation.

While the Israeli government is certainly not a perfect entity, and I can levy a lot of legitimate criticisms, I don’t think they have, as I mentioned, any good choices in this. And if anyone thinks they have a good and reasonable solution.

This whole thing brings up all of those feelings…and I’m going to have to keep writing about it, because the one thing I can’t do is be totally silent.

 

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?