Authentication Assurance – AAL
Also termed AuthN
NIST LEVELS 1-3
1 – some confidence that the person using it is who they say they are (UN/PW)
2 – more confidence that the person using it is who they say they are (MFA)
3- Highest confidence
- proof of possession of a key through a cryptographic protocol.
- AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance
What provides “confidence” – a long list of requirements including: the strength of binding, the inability to spoof, deter MitM
AuthZ - The right to do something, consent, permission
Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to or what they can and cannot do
NIST does not define levels of assurance around the concept of Authorization
Often the two concepts go hand in hand…a person first authenticates themselves to their customer facing portal and then authorizes a transaction. “ Does AAL imply that that any resulting Authorization is also equally strong ?”
What is in use today for AuthZ:
OAuth Framework - OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
However, OAuth 2.0 has limitations:
1) Doesn’t support detailed context about the request
2) Needs to be fine grained – ability to easily add/enforce step up AuthZ, ability to allow/disallow ability to provide consent based on changing conditions.
3) Security – Token leakage and injection
injection threat comes from the fact that client cannot assume that only the resource owner can present it with a valid access token for the resource. Therefore, an adversary can easily inject the leaked or stolen access token (and impersonate the resource owner) when client accepts access tokens from sources other than the return call from the token endpoint. That happens when client uses an implicit flow.
On-deck for OAuth:
CONTEXT – Rich Authorization Request (RAR)
Fine-grained permissions during an authorization request. For example, an app may specify a request such as "let me make a payment of 45 Euros" or "please give me read access to folder X and write access to folder Y".
Other Industry Sectors and Use Cases
PSD2 = Revised Payment Services Directive is an EU Directive, administered by the European Commission to regulate payment services and payment service providers throughout the European Union and European Economic Area.
SCA = Strong Customer Authentication The requirement ensures that electronic payments are performed with multi-factor authentication , to increase the security of electronic payments.  Physical card transactions already commonly have what could be termed strong customer authentication in the EU ( Chip and PIN ), but this has not generally been true for Internet transactions across the EU prior to the implementation of the requirement,  and many contactless card payments do not use a second authentication factor.
Open Banking and Healthcare – Ability for the patient to involve 3 rd parties of their choosing to receive/maintain their PHI and perform transactions on their behalf. (OPEN HEALTH)
- Patient’s right and ability to have access to their own medical data
- Open APIs made available by the EMRs are used to facilitate this access
- Tech companies have already solved the data sharing problem using two protocols to delegate access to sensitive information: OAuth and OpenID Connect. These protocols provide protection of APIs that hold sensitive user information. They make sure that the person who is logging in has permission to access the information, and that they have been properly authenticated.
Next Generation of Authorization Specs
Transactional Authorization (TXAuthZ)
XYZ has several core features that drive its design principles, and these are key to providing a consistent data model:
- Intent registration. This allows the client to start the process off the same way every time by doing request to the authorization server .
- Don't assume the user has a browser. Interaction needs to happen in a variety of ways depending on the capabilities of the client , and only sometimes will a browser be involved.
- Minimize the front channel. When a browser is involved , the protocol seeks to minimize the amount and kind of information that passes through the URLs of the front channel.
- Polymorphic JSON. The protocol elements have different data types that convey additional contextual meaning, allowing us to avoid mutually exclusive protocol elements and design a more succinct and readable protocol. This lets us pass things by reference or by value using the same element field, among other things.
- Key proofing and presentation. While OAuth 2 thrived on client secrets and bearer tokens, XYZ seeks to move beyond that at the base level , making use of a variety of security technologies.
- Ease of transition from OAuth 2. Even though this is not backwards compatible, there should be a clear translation path from OAuth 2 based systems to XYZ .
- Inline negotiation. Whenever possible, the protocol is designed such that discovery and registration are not needed , but they can still be supported.
Healthcare Sector and Its Ability to Utilize AuthN and AuthZ protocols
For Providers/Staff – Sure thing.
These people are identity assured as part of their onboarding process
These people’s identities are maintained in commercial identity and access management services (especially in a large enterprise with multiple systems an individual may have access to) Okta, ForgeRock, etc.
- HR system
- Clinical systems
- Analysis/Reporting systems
Identity & Access Management Systems typically allow SSO and management from a single interface (adding/removing users, changing their access rights, etc.)
For Patients – Not so much
These people aren’t typically identity assured as we understand the concept
The identity is maintained in an EMPI that is used to disambiguate (match/remediate) a patient’s identity
EMPI is not an Identity Service
Access controls for patients exist only around the Patient Portal (username/password)