There are hints of this in a system Amazon used for service to service authentication and encryption. In the initial implementation, a daemon ran on the system syncing data specifically for that host from a central keystone. Applications could then use that daemon to sign content, encrypt outbound traffic, and authenticate clients (at the API level, iirc) while the application never needed to know anything about the keys or algorithms used.

Java folks being Java folks, however, decided that having this external process was a faulty design, for some reason and decided to rewrite it in Java and have it run in the same JVM as the app (with some huge performance implications, at least at first).

Like most tools at Amazon, this extended back to developer desktops, so even development keys could be generated, and autorotated without developers needing to know about them. Group based access ensured they were sent to hosts when new employees entered a group and were removed when they left the group.

This sounds vaguely similar to Managed Service Identities in azure as well. Apps can ask a well-known IP that maps to a local service on the VM host for an oauth token to any azure service, and then it gets back a token with an identity tied to the VM/webapp/function app without needing to do any of the oauth flow itself. I don't think it quite gets to the point of signing content or encrypting connections, though I might have just never seen it.

I'm very interested to read more details about this system. Can you send more details like links, articles, videos, etc?

Interestingly enough, HN comments are the only other reference I see: https://news.ycombinator.com/item?id=16757807

A lot of internal Amazon ideas eventually make their way to the public as AWS offerings, typically with limitations due to them needing to be public offerings without dev teams that can sit in a room at a moments notice and decide on any necessary changes. Typically that means the AWS offering is lacking features compared to the internal version, but eventually teams are encouraged to migrate (I’ve been away from Amazon for about 4 years, but that’s still the impression I get). Lambda, DynamoDB, Code Deploy, Autoscaling Groups, ALB/NLBs (load balancer tied to an ASG), Cloud Watch, SQS, etc. all had internal equivalents which often were better (imho) than the AWS offering. Some were hosted (by another team), some needed to be managed by each team (which made the move to AWS more compelling).

You know, I really wish that Plan 9 had done better. To a very large extent it's Unix carried through to completion.

I think this needs [2013] added to the title.

It says itself that it's a slight modification to a 2002 paper.

The 2002 paper was about a redesign. The original auth system was written up in 1995 by Pike.

Indeed, a date on the paper would have been really useful. It's frustrating that it's not obvious.

Why would it have been useful? The details of the Plan 9 system have remained the same: it's not web design.

It would have saved us this conversation, for a start.

It's not from 2013, which is why I didn't put a 13. None of the Plan 9 guys have had a Bell Labs mail address for like a decade.

The PDF metadata says 2007.