Same difference: burying policy into an authentication token. What is the point? A backend presented with an authenticated identity can do the same thing far easier and far more scalable without any of the downsides like mentioned. A backend server doesn't even need a name/key binding borne by the client at all, let alone bearing policy info as well.
Say I run a storage unit business. When you rent a unit, I give you a code. I have decided (by my policy) that any user with a valid code can access their unit 24/7/365. You come to rent a unit from me. You ask that your code only works on Sundays, because that is the only day you will ever come. You have decided (by your policy) you want something more restrictive than mine. I agree. Someone shows up on Wednesday and tries to use your code. You told me that would never be you, so I deny the entry, because *YOU* told me not to allow it. Semantically, you could say it's 'you did not authorize' , but really it's "I did not not authenticate the identity of this user, based on verified instructions that person provided me". This is really al EKU is. I'm not arguing it's perfect. But that's what it is. On Tue, May 20, 2025 at 1:46 PM Michael Thomas <mike@mtcc.com> wrote:
On 5/20/25 10:33 AM, Tom Beecher wrote:
Nobody in their right mind would
want a login user to carry around a bundle of bits on their laptop of what they are authorized to do
EKU is not 'This certificate defines what the user is allowed to do'.
It is "This certificate is valid to authenticate ONLY IF it is being presented to you in a specific context."
Same difference: burying policy into an authentication token. What is the point? A backend presented with an authenticated identity can do the same thing far easier and far more scalable without any of the downsides like mentioned. A backend server doesn't even need a name/key binding borne by the client at all, let alone bearing policy info as well.
Mike