Delegated Authentication

We all know about Federated Authentication (more commonly known as Single-Sign-On [SSO])… so what is Delegated Authentication? I’d argue it’s a necessary part of the larger Delegated Authorization problem space. So let’s start with a use case.

Alice and Bob are married and in their marriage, Alice takes care of all the medical aspects. This includes having accounts at multiple sites for supplements and medical health portals. In a sad turn of events, Alice contracts cancer and passes away. Bob now needs to access many of these sites to stop subscriptions for supplements, or change medical information.

I hope many of you are saying, why not just use User Managed Access (UMA) for this? Alice can authorize Bob to access her resources at the supplement site; problem solved? However, that requires the site to support UMA and as yet UMA has not had a large adoption rate. This is less a statement about the usefulness of UMA and rather, I believe, at statement about the understanding of the need to support delegated authorization use cases.

The current solution

Today, this situation is often solved by Alice sharing her password for the sites with Bob and allowing Bob to login as Alice (what I call impersonation). This solution is very simple if that work has been done ahead of time, but it does hide information from the supplement site and in some cases may actually break the terms of service.

An alternative proposal

What if instead, Bob could present a “delegated authentication credential” to the supplement site that proved he was authorized to access Alice’s account now that Alice is no longer living? A number of things would need to be true for the supplement site to accept such a credential…

• Proof that Alice is dead or incapacitated
• Proof that Bob is authorized to act as Alice’s “fiduciary”
• Proof that the entity presenting the credential is Bob

With delegated authentication instead of impersonation (aka password sharing), the supplement site can make much better decisions allowing Bob to change/stop subscriptions while restricting Bob from taking other actions as an example.

I realize that this is a bit of paradigm shift in the way we think about authentication and it also provides a new attack vector (how difficult is it for an attacker to obtain a “delegated authentication credential” for a user). I have thoughts about other use cases, but I’ll stop here and ask for feedback on whether this is just too far out there? Or is this something that needs to be considered as more of our lives become digital?

P.S. I also realize that no sites support this mechanism either, and doing so correctly has its own complexities. This model may fit a bit better with the issuer-holder-verifier (aka Wallets) model while UMA works well with existing federated authentication models.