On 5/20/25 11:12 AM, Tom Beecher wrote:
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.
Unless you're willing to say that whatever is doing the authz/policy is *offline* -- ie, can't look that policy up in real time -- this can all be done using normal online mechanisms. That is, "server, can is this identity allowed to do this or that?" in your example. I'm not arguing that it doesn't work as stated. I'm arguing that they bring a tremendous amount of cert baggage -- business models, enrollment, revocation, etc, etc -- that is really hard to justify under any normal circumstance. Asymmetric keying unfortunately involves way too many people thinking that once they are involved, certs are necessary. It need not be, and in fact the vast majority of cases would greatly simplified to just get rid of certs entirely, even the basic name/identity binding they provide. Mike