Year: 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?

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.

 

The world continues to be a scarier place. This week, Senator Chuck Schumer gave a speech on the floor of the Senate, trying to explain how American Jews, in general, feel about the situation. Schumer is the highest ranking Jewish official in the United States, in fact, the highest ranking Jewish official ever.

In my opinion, his speech and Biden’s speech of support for the victims on October 7th were some of the more powerful pieces of political oratory in recent memory.

Schumer covered the points that I keep trying to express myself, noting that Jews “are worried—quite naturally, given the twists and turns of history—about where these actions and sentiments could eventually lead.”

Earlier this week, at a high school not far from where I live, students tried to get a teacher fired who merely attended the March for Israel in Washington. To agree with the Senator…walking out of school in support of Palestinians is legitimate, even protesting within the school, but making this teacher a target is not. The teacher wasn’t teaching their personal views, and ended up hiding and fearing for their safety.

There is no moral justification for what Hamas did on October 7th. But too many people believe otherwise.

Three individuals in Brooklyn this past Saturday approached Jews going about their business, and unprovoked, punched or kicked them, and apparently yelled, “Free Palestine.”

The IHRA has a working and nuanced definition of anti-semitism that is definitely worth reading. While I may be able to say that criticism of Israel in itself is not anti-semitism, many of those who are protesting demonstrate that they aren’t just criticizing Israel.

 

Version 4.4.0 of the WordPress IndieAuth plugin was released today, and it contains a lot of changes, but very little in terms of noticeable ones.

The biggest changes involve the removal of the already hidden by default Remote IndieAuth code, which allowed you to use a third-party indieauth endpoint. The plugin now only allows you to use the local code.

Why is this? Because the plugin is a full IndieAuth endpoint. If someone truly is interested in using someone else’s endpoint, then I’ve put that code aside if it is needed.

I also reworked a lot of the code based on the newest revision of the IndieAuth specification. I jumped on the revision bandwagon early for the plugin, but I had essentially bolted the new pieces onto the older code. I tried to move things around to integrate it more.

I had missed updating the Web Sign In feature to support the latest revision. Web Sign In is effectively an IndieAuth client. It allows you to log into your WordPress site using IndieAuth instead of a username and password.

So, you put in a URL, authenticate to that URL, and it will log you into your site.  This is what indielogin does, although if there is no IndieAuth endpoint, it falls back on other things and the WordPress version does not..although it could in theory…just not sure what services it would fall back to.

This feature allows things like logging into a multi-user WordPress site with your personal WordPress site by linking the two and being logged in or logging into the personal site.

But this isn’t the end of it, because I have more ideas I’d like to play with for the future.

• Improve the process for how the system decides that a user is in fact, the same as the logged in user on the other site, possibly by having a list of approved domains that can authenticate?
• What if Web Sign In could be made the default for logging in?
• What if the act of trying to log into a WordPress site with your own website created a subscriber level user(a user with no privileges)? That user could then be issued permissions to view non-public information.
• More with Ticketing…which means more enhancements to allow a logged in user to see specific ‘private’ posts inside and outside of feeds.