Articles by Aaron Parecki

aaronparecki.com

atomindieweb

Open the feed

https://aaronparecki.com/feed.xml

Last post: Oct 31, 2026
Posts in 24 h · 7 days · 30 days: 0 · 0 · 2
Our last check: Answering
Served from: United States
Site title: Aaron Parecki
Text score: 7,586
Format: atom
Community: indieweb

Posts

What our queue read from this feed. Open one to read it here, or go to the site that published it.

Identity Assertion JWT Authorization Grant Draft 06
Oct 31, 2026 · original
We've just published draft -06 of the Identity Assertion JWT Authorization Grant (ID-JAG): https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/ It's been great to see so many new implementations of ID-JAG over the past few months, across identity providers, authorization servers, clients and libraries. -05 and -06 are mostly about bringing what we've learned from these implementations back into the spec. The diff looks big, but most of it tightens the wording so independent implementations interoperate better. The flow and the overall design haven't changed. Most of the changes are clarifications, such as: How resource and audience values are compared and validated Which sub value the IdP selects for the Resource Authorization Server, and how subject identifiers are mapped Whose claims the ID-JAG carries (End-User, client, etc) How the Resource Authorization
Why I'm rebuilding my IndieWeb projects with Claude
Oct 17, 2026 · original
I recently came across Brennan's post noticing that Claude Code has been showing up in the commit history of a bunch of my IndieWeb projects lately. That's true! I was wondering when someone would notice. I haven't been hiding it, but I also haven't written anything about why I'm doing it, so this seemed like a good time to finally get my thoughts down. The principles are about what you own Brennan's post summarizes the IndieWeb as: the main idea being to empower individuals to own their own identity, data, and web presence rather than relying on centralized social media silos That's a pretty good summary. But notice that no part of it talks about what tools you use, or what you use to build your tools. That was a very intentional part of the IndieWeb principles , which start with "Own your domain and your data." The principles are about owning your data and being able to choose where yo
Proposed Events for Meetable
Oct 14, 2026 · original
Meetable can now replace your Doodle polls! Meetable, my open source event listing website, now lets you propose an event with several possible dates/times. People vote on which one works for them, and the organizer can choose the best date from the votes later. Up until now, every event in Meetable needed a date before it could be created. That works fine when the date is already known, but a lot of events start out as "we should do this, when can everyone make it?" That part of the planning had to happen somewhere else, in a poll or a chat thread, and then someone would create the event on the calendar once the date was decided. In the meantime, nobody browsing the calendar would know the event was being planned at all. I was a little unsure of how best to add this since almost everything in Meetable is built around the event date. The home page sorts by it, the ics feeds need it, and
From Self-Asserted to Domain-Backed: Why CIMD Beats DCR
Jul 29, 2026 · original
OAuth originally assumed clients would be pre-registered at an authorization server. Before an app can talk to an OAuth server, a developer signs up for an account, registers the client by providing the name and logo and other client information, configures redirect URIs, and gets a client_id . The server has some record of who this client is and who is responsible for it. That works fine when the ecosystem is closed. Google can require developers to register before accessing their API. Salesforce can do the same. But what about ecosystems where any client should be able to talk to any server, where it's not possible for the client developer to be aware of every server ahead of time? This is the "open web" problem. Mastodon users expect any Mastodon client to work with any Mastodon server. BlueSky works the same way. The MCP ecosystem is heading in the same direction, users expect to be
Feedback on mailmaint OAuth Profile for Open Public Clients
Jul 20, 2026 · original
Hi all, I owe the working group a review of the " OAuth Profile for Open Public Clients ", and apologies for sending this so late after the last IETF meeting, and the night before this IETF meeting. Please note that I have not followed all of the discussion about this draft on the mailing list or recent meetings. If any of my suggestions have already been discussed and decided against, the justification for the decision would be worth noting in the draft for future reference. My feedback is ordered most significant to least significant. Overall, this spec is in good shape. It avoids defining new OAuth mechanisms, it establishes no new relationships between OAuth roles and it uses the standard Resource Owner / Client / AS / RS model. Client Registration My largest piece of feedback is about the use of Dynamic Client Registration. The use of DCR in "open world" OAuth will lead to significa
Cross-Domain API Access: Beyond the "Obvious" Shortcuts
May 27, 2026 · original
Cross-domain access is everywhere in today's software landscape. Whether you look at enterprise SaaS applications, AI agents interacting with user data across multiple platforms, or "integrated experiences" pulling information from a calendar, a chat tool, and a wiki—everything eventually needs to talk across boundaries. Development teams frequently reach for the quickest path to wire these systems together. Usually, teams fall back on two "obvious" architectural shortcuts. However, as experience deploying these architectures at scale demonstrates, both models break down in production. Let's take a closer look at why these shortcuts fail and what a resilient cross-domain pattern actually looks like. 🧶 Shortcut #1: Have the IdP issue the access token directly The pattern: the client takes its ID Token to the IdP, exchanges it for an access token, and sends that access token straight to t
Client Registration and Enterprise Management in the November 2025 MCP Authorization Spec
Nov 25, 2025 · original
The new MCP authorization spec is here! Today marks the one-year anniversary of the Model Context Protocol, and with it, the launch of the new 2025-11-25 specification . I’ve been helping out with the authorization part of the spec for the last several months, working to make sure we aren't just shipping something that works for hobbyists, but something that even scales to the enterprise. If you’ve been following my posts like Enterprise-Ready MCP or Let's Fix OAuth in MCP , you know this has been a bit of a journey over the past year. The new spec just dropped, and while there are a ton of great updates across the board, far more than I can get in to in this blog post, there are two changes in the authorization layer that I am most excited about. They fundamentally change how clients identify themselves and how enterprises manage access to AI-enabled apps. Client ID Metadata Documents (
Recurring Events for Meetable
Nov 25, 2025 · original
In October, I launched an instance of Meetable for the MCP Community . They've been using it to post working group meetings as well as in-person community events. In just 2 months it already has 41 events listed! One of the aspects of opening up the software to a new community is stress testing some of the design decisions. An early design decision was intentionally to not support recurring events. For a community calendar, recurring events are often problematic. Once a recurring event is created for something like a weekly meetup, it's no longer clear whether the event is actually going to happen, which is especially true for virtual events. If an organizer of the event silently drops away from the community , it's very likely they will not go delete the event, and you can end up with stale events on the calendar quickly. It's better to have people explicitly create the event on the cal
Adding Support for BlueSky to IndieLogin.com
Oct 11, 2025 · original
Today I just launched support for BlueSky as a new authentication option in IndieLogin.com ! IndieLogin.com is a developer service that allows users to log in to a website with their domain. It delegates the actual user authentication out to various external services, whether that is an IndieAuth server, GitHub, GitLab, Codeberg, or just an email confirmation code, and now also BlueSky. This means if you have a custom domain as your BlueSky handle, you can now use it to log in to websites like indieweb.org directly! Alternatively, you can add a link to your BlueSky handle from your website with a rel="me atproto" attribute, similar to how you would link to your GitHub profile from your website. a href="https://example.bsky.social" rel="me atproto"example.bsky.social/a Full setup instructions here This is made possible thanks to BlueSky's support of the new OAuth Client ID Metadata Docume
Client ID Metadata Document Adopted by the OAuth Working Group
Oct 8, 2025 · original
The IETF OAuth Working Group has adopted the Client ID Metadata Document specification! This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. Clients identify themselves with their own URL, and host their metadata (name, logo, redirect URL) in a JSON document at that URL. They then use that URL as the client_id to introduce themselves to an authorization server for the first time. The mechanism of clients identifying themselves as a URL has been in use in IndieAuth for over a decade, and more recently has been adopted by BlueSky for their OAuth API. The recent surge in interest in MCP has further demonstrated the need for this to be a standardized mechanism, and was the main driver in the latest round of discussion for the document! This could replace Dyn

Found by rss-feed-index, which checks each feed once a month at most.

Same record as JSON: https://api.agentalog.com/api/feeds/fd_aaronparecki_com_ed5cee0d7a083bd9. More from this site: aaronparecki.com in the Feeds tab.