71–80 of 91 posts
Earlier quoted context omitted.
That's when you turn to the RFC2119 all-caps requirement levels!
What I find strange about RFC2119 is technically RFC8174 amends it, yet the amended text never seems to be used.
Nice! I'd like to fix the prior abstract. Auth and auth upsets me greatly cos we have: Authentication & Authorization and we call both/either auth. Hence please help me make this a thing: AuthENTIcation & AuthORIzation : ENTI & ORI ENTI- can you enter, ORI (or ORIZ) what can you do?
or 4entic5 and 4oriz5, inverting the k8s, i18n pattern...
pronounced "forentics" and "forizes"...
somebody stop me!
Earlier quoted context omitted.
They clearly mean capabilities. https://en.wikipedia.org/wiki/Capability-based_security > Capabilities achieve their objective of improving system security by being used in place of forgeable references. A forgeable reference (for example, a path name) identifies an object, but does not specify which access rights are appropriate for that object and the user program which holds that reference. Consequently, any attem…
Some nice Object Capability technologies not mentioned in the Wikipedia article: https://capnproto.org (used by Cloudflare) https://spritely.institute/goblins (with wasm support via Hoot) https://ocapn.org (where things come together in a future open standard)
(shameless plug)
Earlier quoted context omitted.
I think you've got the right idea, though in practice the initial "authentication" question (you are who you say you are) is very closely linked to the initial "authorization" evaluation (can you enter).... because in most systems the only "can you enter" authorization required for access is in fact that you are who you say you are. But not all systems work this way. There are some systems where you can log in succes…
One problem is that treating authentication as a "can you enter" authorization is predicated on the idea of a session-based system with two states, logged in or logged out. But there are many scenarios where e.g. taking some particular action requires authn and authz, regardless of login status. A simple example is performing some destructive action. The distinction between authentication and authorization allows mod…
Not long ago I designed an authentication system which had to be disconnected from authorization pretty fully. The authentication was global in a multi-tenanted system, but access to any tenant was authorized at the tenant level (as well as all other authorization concerns). To be fair, there was some global authorization concerns, but the vast majority of authorizing actions, including tenant access was governed at the tenant level after authentication.
excellent article, very thorough and nuanced explanation.
Earlier quoted context omitted.
shan't vs. oughtn't! Both are equally horrendous.
Shan’t is a lot of fun. It feels like such a misuse of contractions. But it works. And it’s fun to say. Also fun: yesn’t. Yes, but really no.
Nice! I'd like to fix the prior abstract. Auth and auth upsets me greatly cos we have: Authentication & Authorization and we call both/either auth. Hence please help me make this a thing: AuthENTIcation & AuthORIzation : ENTI & ORI ENTI- can you enter, ORI (or ORIZ) what can you do?
This has already been solved well-enough with AuthN and AuthZ as distinct names.
Never change programming/maths in holding onto terrible naming conventions and making really hard stuff even harder to understand (CQRS anyone?)