Articles by Aaron Parecki

aaronparecki.com

atom indieweb

Open the feed

https://aaronparecki.com/feed.xml

Last post: Jul 29, 2026
Posts in 24 h · 7 days · 30 days: 0 · 0 · 0
Our last check: Answering
Served from: United States
Site title: Aaron Parecki
Text score at discovery: 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.

Solving the Missing Trust Anchor in Dynamic Client Registration with CIMD
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
Meetable Release Notes - October 2025
Oct 4, 2025 · original
I just released some updates for Meetable , my open source event listing website. The major new feature is the ability to let users log in with a Discord account. A Meetable instance can be linked to a Discord server to enable any member of the server to log in to the site. You can also restrict who can log in based on Discord "roles", so you can limit who can edit events to only certain Discord members. One of the first questions I get about Meetable is whether recurring events are supported. My answer has always been "no". In general, it's too easy for recurring events on community calendars go get stale. If an organizer forgets to cancel or just stops showing up, that isn't visible unless someone takes the time to clean up the recurrence. Instead, it's healthier to require each event be created manually. There is a "clone event" feature that makes it easy to copy all the details from
San Francisco Billboards - August 2025
Aug 7, 2025 · original
Every time I take a Lyft from the San Francisco airport to downtown going up 101, I notice the billboards. The billboards on 101 are always such a good snapshot in time of the current peak of the Silicon Valley hype cycle. I've decided to capture photos of the billboards every time I am there, to see how this changes over time. Here's a photo dump from the 101 billboards from August 2025. The theme is clearly AI. Apologies for the slightly blurry photos, these were taken while driving 60mph down the highway, some of them at night.
Enterprise-Ready MCP
May 13, 2025 · original
I've seen a lot of complaints about how MCP isn't ready for the enterprise. I agree, although maybe not for the reasons you think. But don't worry, this isn't just a rant! I believe we can fix it! The good news is the recent updates to the MCP authorization spec that separate out the role of the authorization server from the MCP server have now put the building blocks in place to make this a lot easier. But let's back up and talk about what enterprise buyers expect when they are evaluating AI tools to bring into their companies. Single Sign-On At a minimum, an enterprise admin expects to be able to put an application under their single sign-on system. This enables the company to manage which users are allowed to use which applications, and prevents their users from needing to have their own passwords at the applications. The goal is to get every application managed under their single sig

Discovered by the rss-feed-index crawler, which checks each feed at most once a month.

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