My name is Ben Kehoe. I’m an AWS Serverless Hero. I’ve spoken at re:Invent. I meet regularly with teams across AWS. I’m followed by @awscloud on Twitter. But AWS doesn’t know who I am.
On GitHub, I’m benkehoe. I’m benkehoe when I’m building personal projects like aws-whoami, and I’m benkehoe when I’m building projects for iRobot like cfn-custom-resource (granted, it’s been a long time since we’ve released anything new), and I’m benkehoe when I’m contributing to open-source projects.
On AWS, I am:
- Any one of several hundred IAM roles within accounts in iRobot’s AWS Organization, none of which bear my name or are unique to me
- An IAM User in my personal AWS Organization
- A user in iRobot’s AWS SSO directory
- A user in my personal AWS SSO directory
- One or more AWS accounts for the AWS Serverless Application Repository
- An account on portal.awsevents.com for AWS re:Invent, and maybe the same account for AWS re:Inforce, which uses an email address as an identifier
- An account for the AWS Customer Council, which uses an email address as an identifier
- An account for Amazon Chime
- Any number of entries in AWS marketing databases for where I’ve been required to enter the same details each time I sign up for a webinar, event, etc.
- I haven’t deployed anything to ECR Public yet, but if I do, I think the identity is also an AWS account?
- I don’t use AWS IQ, but your identity there is tied to a single IAM principal
- I don’t use the AWS Partner Network Portal, but apparently that has its own directory as well
None of these identities represent Ben Kehoe, the human. At best, you might be able to combine some of these to separately represent Ben Kehoe the Cloud Robotics Research Scientist at iRobot, and Ben Kehoe the private citizen.
AWS needs to have a single identity that is tied to Ben Kehoe, the human. When I go to re:Invent, the identity tied to my conference badge should not be specific to my employer nor independent of my employer. I am both an AWS user in my own right, and an AWS user in my job at iRobot.
What I don’t need is a single set of credentials that gives me access to everything I do across these different identities. When I’m accessing iRobot resources, I should be required to have authenticated with my iRobot credentials with AWS SSO through Okta. When I’m accessing my personal resources, the authentication that gives me access to iRobot resources is irrelevant; I should have to be authenticated through the identity provider I’m using in my personal projects. And I don’t need to be simultaneously authenticated for both of these; authenticating as one can invalidate my authentication as the other. But no matter what, the identity I’m using should carry with it the identifier for Ben Kehoe the human.
I don’t think this human identity should be involved in authorization; it should not be a principal in IAM, for example, nor should it even be an context key that you could use in an IAM policy. What it should be is an identifier (that can be used in public, I think) that carries with it context that’s tied to the human, to make the human’s user experience better; and it should be the identity that’s used when interacting with AWS outside the bounds of AWS accounts and resources (e.g., events, the forums, AWS IQ).
What benefits would this provide?
Imagine that customization of the AWS console was associated with the human identity. Every account, with any role, would look the way you want. More context would remain as you switched accounts and back again.
For public registries in AWS, it provides the unique identifier by which to organize the registry. The AWS accounts and IAM principals publishing to the registry can vary but the outward-facing identity will remain the same.
You’d have a persistent identity across all the AWS events you attend. It could be a basis for organizing meetings, birds of a feather sessions, or even more fully-featured social connection (presuming safety was built in).
You’d have a persistent identity for online communities: the AWS forums (or hopefully an improved replacement for them) needs exactly this sort of identity to function correctly; no IAM principal nor AWS Organization-linked identity will suffice.
AWS would have a single communication channel with you: AWS is a firehose of information; there are way too many new features, services, blog posts, videos, solutions, and any number of other kinds of content coming out every day, and basically no way to filter it. A unique identity would allow AWS to have a channel to deliver content to you that would be customized to your interests. Hear about all the latest developments in the minutiae of the services you care about, and never hear about WorkDocs rolling out a feature to the Frankfurt region — unless you’re using WorkDocs in Frankfurt, and then you’d know exactly when that feature you’ve been desperately waiting for arrives.
What’s hard about this? Everything; it’s deeply tied into information security questions. I don’t pretend that this isn’t a complex endeavor, but it is a necessary one.
AWS stands at a crossroads. The volume of content means the need for personalized communication has never been greater. The move towards SaaS products not tied to a single AWS account, to complement existing and new building-block services, is finding existing identities to be insufficient (Honeycode and EMR Studio are recent examples). And creating identities that are scoped to a particular context (e.g., an AWS Organization) is the easy way out. But as soon as one of those identities has a public identifier, we’ve passed through a one-way door.
AWS cannot continue to lack an identity for humans. And when they approach an identity for humans, they must not doom customers to a poor, fractured user experience by making that identity specific to an AWS Organization or corporate identity provider.
