Last month, the IDPro newsletter published an OpEd entitled I’ll pass (for now) on Passkeys. In it, the author discusses their caution in adopting passkeys at this time due to perceived interoperability and usability challenges. Out of concern that those perceptions might hinder the growth of passkeys, and thereby limit options for users and relying parties who need better credentials than passwords, I’d like to share my own perspective below.

First, let’s clarify some language around passkeys.  Passkeys are defined as FIDO discoverable credentials.  Discoverable credentials reside within the authenticator, whether it is a hardware device, TPM, or passkey provider. Passkeys are distinguished from non-discoverable FIDO credentials, which are embedded in the credentialID returned to the relying party (RP) at registration and thus stored by the RP. Yubico has a good writeup on the concepts.

Passkey Options

Within the realm of passkeys, there are two additional options: device-bound passkeys and synced (synchronized) passkeys. Device-bound passkeys are inherently bound to the device – a Trusted Platform Module (TPM), Trusted Execution Environment (TEE), or Secure Element (SE).  These passkeys cannot be exported or backed up, if the device is lost, reset, or broken, the credentials are lost and cannot be recovered. Synchronized passkeys (synced passkeys) are stored within a passkey provider synchronization (sync) fabric and may be moved between devices, shared, and (in some cases) exported.  The sync fabric ensures high availability and reduces the risk of loss of the credential.

Fundamentally, all FIDO credentials – passkeys and non-discoverable credentials – have the same security model. The credentials are cryptographic key pairs that are origin-bound, enabling strong phishing resistance. Due to the use of asymmetric cryptography, there is no secret that can be stolen from the RP, unlike passwords or OTPs.  

More on Synced Passkeys

The introduction of passkeys —what we now call synced passkeys— in 2022 changed our approach to phishing-resistant credentials. With synced passkeys, users can create credentials that automatically sync across the cloud within a single ecosystem (e.g., iCloud). This synchronization ensured the availability of synced passkeys even if a device was lost. However, these credentials were only available within that vendor’s ecosystem in the initial deployment. Cross-device authentication partially solved this problem by allowing devices to be used across ecosystems for authentication without sharing the passkey. Synced passkeys alleviate the concerns for consumer and enterprise markets where managing device-bound credentials creates unacceptable user friction.

In 2023, we saw the emergence of third-party passkey providers, including traditional “password managers,” enabled on multiple platforms. Passkey providers offer alternatives to a platform’s passkey implementation, allowing cross-ecosystem syncing within the provider’s ecosystem. Today, there are 25 different passkey providers listed in the Passkey Authenticator AAGUIDs list from various providers, including small companies, large companies, and open-source implementations.  Today, passkey providers are available for all major browsers and operating systems. 

Security Spectrum

All credentials reside somewhere along a security spectrum; this is no different with passkeys.  

In a 2023 study by Bitwarden, only 30% of respondents use password managers (credential managers), while 84% of users reuse passwords across sites! Any increase in the use of a credential manager raises the bar for end-user security, whether the user chooses a password or a passkey. If users choose passkeys, let’s celebrate! We just reduced authentication friction for the user with a higher-quality, phishing-resistant credential, reducing risk for both the user and the relying party.   

Synced passkeys introduce new risks compared to the traditional FIDO hardware key deployment model. Synced passkeys may be leaked through credential sharing, insecure credential export, attacks against the passkey provider, or attacks on the provider’s client application. All of these attacks are possible against credential managers today, yet we broadly agree that using a credential manager effectively reduces the risks associated with passwords. 

Passkeys Support

Recently, NIST published NIST Special Publication 800-63Bsup1, which outlines the properties of passkeys that reach Authenticator Assurance Level 2 (AAL2).  Passkeys with demonstrable properties that meet or exceed the requirements outlined in Section 4 may meet the high bar of AAL2 credentials. Since passkeys are commonly considered a “password replacement”, it is reasonable to consider that all passkeys are AAL1. Yet this classification isn’t fine-grained enough to distinguish that even within AAL1, some credentials are better than others. Passkeys are clearly superior to passwords, even though they are both AAL1 credentials. 

In practical terms, vendor lock-in for passkeys does not exist. Any service supporting passkeys should allow the registration of multiple passkeys per account. Users operating across platforms or ecosystems can register multiple passkeys in different providers or use a cross-platform passkey provider. The Cross Device Authentication flow can be used to authenticate on a client that doesn’t have a passkey using their phone or tablet (“authenticator”), which has a passkey.

Today, some passkey providers allow you to export your passkeys to disk for backup as you see fit: KeepassXC, ProtonPass, and BitWarden. While I don’t recommend this option, it exists. 

What’s Next

The FIDO Alliance is developing a new Universal Credential Exchange protocol to allow the secure transport of passkeys and other credentials between different credential managers. I hope we’ll see public implementations of Universal Credential Exchange soon.

Passkeys are not perfect, but they continue to evolve through the hard work of members in the FIDO Alliance and W3C. Don’t let perfect be the enemy of good and overlook passkeys.  Identify use cases for passkeys in your environment as a password replacement, second factor, or even as an AAL2 multi-factor credential. Together, we can reduce the use of knowledge factors, phishing, and related fraud while delivering a better user experience.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

Author

Dean H. Saxe is a Principal Engineer in the Office of the CTO of Beyond Identity, founding member of IDPro, IDPro Body of Knowledge author and reviewer, the first person to obtain the CIDPRO certification, and co-chair of the FIDO Alliance Enterprise Deployment Working Group (EDWG). Beyond the realm of Identity, Dean is passionate about traveling, cycling, camping, board games, cooking, and spending time with his wife, two kids, and two dogs.

The post Don’t Pass on Passkeys appeared first on IDPro.

Well, it’s been another busy few months for the authorati (credits to Omri Gazitt of Aserto and Sebastian Rohr of Umbrella Associates for coining the term). The OpenID AuthZEN Working Group was busy putting the final touches on its first implementer’s draft all the while spreading the gospel at several events. Let’s rewind the tape and sum up the highlights.

May 2024 – Identiverse – AuthZEN Interop

We were fortunate enough that both Identiverse and OpenID lent us rooms during the event to finalize our initial interop: 12 different implementations took part and successfully tested their capabilities against a Rick & Morty-inspired demo app. So, what does the initial interop include? A fully spec’ed-out binary authorization API that allows clients to send an authorization request in the form of a yes/no question e.g. “Can Alice view document #123?” and get a decision back in the form of a boolean. For those familiar with XACML, this is a streamlined and simplified version. For developers and API lovers out there, you can check out the sample AuthZEN Postman library. Omri (Aserto) also maintains a website that walks readers through the interop.

In addition, there were several talks worth calling out:

• The Authorization Conversation panel led by Eve Maler – AI-generated summary
• Read Out from the AuthZEN Interop Event – slides

The latest version of the implementer’s draft can be accessed here. Readers interested in providing feedback should use the issues feature in the AuthZEN GitHub repository.

June 2024 – European Identity Conference – AuthZEN Interop (take 2)

Attendees and speakers of Identiverse had a mere 48 hours before heading out to Berlin for a second generous helping of IAM. EIC was also replete with authorization talks and AuthZEN presentations. My peer (and fellow editorial member) Alex Babeanu and I took part in a panel with fellow IAM expert Patrick Parker (EmpowerID): Unpacking Authorization Approaches: Policy as Code Versus Traditional Business Needs. You can watch the replay here.

On Thursday, Allan Foster, Adam Rusbridge, Alex Babeanu and I talked about the importance of standardization in authorization. All four of us are members of OpenID AuthZEN and both 3Edges and Axiomatics are part of the 12 conformant implementations.

On the last day of the conference, Gert Drapers led the second AuthZEN interop: the focus was on use cases brought by individuals from the manufacturing and banking sectors.

July 2024 – AuthZEN meets OAuth at IETF

OAuth focuses on “access delegation” and of course authentication. Authorization (ABAC/ReBAC or other models) focuses on access control. Can both models be used together? That’s what Eve Maler, Justin Richer, Allan Foster, and I attempted at IIW last October (notes). This led to a first attempt in the form of the AuthZEN Request/Response Profile for OAuth 2.0 Rich Authorization Requests which was proposed during IETF 120 in Vancouver. The profile suggests leveraging the AuthZEN request format to send a RAR request from a client to the authorization server. The hope is that this will increase interoperability and “integrability” between OAuth-based systems and “policy decision points”. For more information, check out the presentation slides or join OpenID’s Slack for a live discussion.

What’s next for AuthZEN?

The WG is already actively working on the next iteration of the standard. Members have reached consensus on a batch authorization request API (sometimes called boxcarred requests). We are planning an interop at AuthenticateCon in October and IIW a few weeks later. If you would like to join the WG, especially as a customer (non-authorization vendor) organization, we’d love to hear about your use cases. Join us on OpenID’s website

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

Author

In his role as CTO, David drives the technology vision and strategy for Axiomatics based on both identity and access management (IAM) market trends as well as customer feedback. He also leads the company’s strategy for standards and technology integrations in both the IAM and broader cybersecurity industries. David is a founding member of IDPro, a co-author of the OASIS XACML standard, and an expert on standards-based authorization as part of an overall IAM implementation. Most recently, David led the design and development of Salesforce’s identity offering, including customer identity and access management (CIAM) solutions.

The post Updates from AuthZEN appeared first on IDPro.

By Atul Tulshibagwale and Sean O’Dell

Security online is no longer a periodic snapshot of users and authorizations. We need an efficient architecture to respond to events and updates in real-time.

Background

Recently, Andi Hindle (of the Identiverse conference fame) and Ian Glazer (former SVP, Identity Product Management at Salesforce, and now President of Weave Identity) both published blog posts about how the area of identity and access management is changing to a more continuous model. 

• Andi’s blog: The Era of Continuous Identity
• Ian’s blog: Misalignment and the rise of Event-Time IAM

Earlier work around the Identity Fabric popularized by Gartner defines a framework for how different identity systems could collaborate to provide more complete security coverage for all constituent users and all protected systems. Among its “Must-Have” characteristics are things like “event-based integration connectivity” and “adaptive continuous, risk-aware and resilient security”. These also point to a continuous and event-driven methodology to ensure identity security…enter the concept of continuous security.

A Paradigm Shift

All this got us thinking: we’re seeing a paradigm shift in how we think about security. It’s a paradigm where there is no single point of control—each system needs to enforce its own access security—but you still need to define centralized policies and management.

Lately, the real security action has shifted to identity and the behavior of users. The specific concern here is whether that behavior represents legitimate usage or malicious behavior, either because an attacker has assumed a user’s identity or the user themself is deviating from what is or has been perceived as “normal”.

What does this mean when all your services run independently in a zero-trust architecture? There is no central point of control, other than the login-time participation of the identity provider. Like Ian said in his blog post, the “event-time” dimension comes in after you login, and this is what leads to the “Continuous Identity” state that Andi mentions in his blog.

What Is the Continuous Security Paradigm

So let’s consider a new model more suited to today’s dynamic security requirements: the Continuous Security Paradigm. As we move forward in identity, we are emulating behavioral characteristics from the real world in the digital realm. As an example, say you are having work done on your house and have contracted with a company. The company has notified you in advance that someone named Erik will arrive at a certain date and time to do the work.. When Erik shows up at the expected date and time, do you go back and verify if Erik is employed by the company doing the work? You probably don’t. Instead, you make a decision based on context and risk. You know to expect a person named Erik to be at your home between a certain time from a certain company to perform a task. This is exactly what zero-standing access is in the digital realm. Would you always grant Erik access to your home just because of this one task that they had to perform? No, that is too risky. These same principles are why the shift to a Continuous Security Paradigm is not only needed but required. 

The Continuous Security Paradigm is a system-centric view of security. Your particular application or system is one node in a tapestry of loosely coupled nodes. In addition to the usual data plane and control plane, this paradigm introduces a new “Signals Plane” of asynchronous communication, which enables event-time processing. Runtime decisions are, as expected, made in the Data Plane, but they are based on the context derived from the Signals Plane. The Control Plane defines the trust topology of the Signals Plane.

The Control Plane

Rather than viewing the network as a uniform “fabric”, the Continuous Security Paradigm models it as a loosely coupled and more diverse tapestry that captures the differences in how much each node trusts another, and who owns individual nodes. A node in such a network is not about physical or virtual connectivity as represented by Virtual Private Clouds (VPCs) or firewalls, but a logical definition of what information is asynchronously communicated (either received or transmitted) between which nodes in the tapestry. This may include nodes that you “own”, e.g., VPCs, SaaS tenants, or IaaS tenants, but it may also contain nodes that are trusted sources of public information (e.g., public securities data or dark web credential monitoring data).

The control plane is used to specify this trust topology. Specifically, how each node is connected to another with respect to the trust, entities, and attributes. For example:

1. A CRM node trusts the HR node as the authoritative source for employee entities and their attributes such as their cost center.
2. An application node trusts the HR node as an authoritative source for employee entities and trusts the CRM node as the authoritative source for customer entities and as a non-authoritative source for employee entities, which it correlates with the authoritative employee entity source, the HR node.
3. The CRM node trusts the application node to receive customer entities and certain attributes of customer entities from it.
4. The HR node trusts the CRM node and the application node to receive employee entities and specific attributes of those entities.

The control plane also specifies the frequency of ingestion or transmission of specific entities to / from specific nodes. It also specifies the policies to be applied when using information received from other nodes.

The Signals Plane

The signals plane enables each node to asynchronously collect the entities and attributes that are important to its own data-plane decisions. It also enables each node to communicate any changes to its entities and attributes that may be relevant for other nodes it trusts. The asynchronous ingestion and transmission of trusted data enables each node to decouple its runtime decisions from the availability and latency characteristics of other nodes in the network. Open standards such as the OpenID Shared Signals Framework (SSF) are designed for conveying such information asynchronously.

The Data Plane

The actual access decisions in response to API calls or user requests are done in the data plane. The signals plane enables each node to ensure that it or other nodes in its network do not make decisions based on outdated information. Yet, because the information is conveyed asynchronously, the decisions each node makes are based on “event-time”, or “continuously updated” information – without sacrificing efficiency. When a data plane event occurs, e.g., a user attempts to access specific data in a node, the policies specified by the control plane govern how the asynchronously ingested data and the runtime data from the data plane are used to make decisions.

Computation in CSP

To ensure security for an application, e.g., one node in your organization’s network, you need to:

1. Obtain trusted signals about all interesting interactions/events (identities, devices, environmental factors (e.g., IP location, geo-location, etc.). Some signals are obtained from the user request, but most may be obtained asynchronously using the signals plane from other nodes
2. Make your own policy decisions about granting or denying access: Your application or system needs to have its own rules to determine access and know user behavior as far as your own application is concerned
3. Communicate changes to other nodes: The control plane may obligate you to communicate any changes to certain entities to other trusted nodes, at a certain cadence. Doing this enables all nodes to make decisions based on event-time data.

Why introduce a new paradigm?

We’re seeing escalating tensions on a couple of axes: Between having to constantly re-evaluate access decisions, the desired performance, and the computational impact of doing so; and between the independence and resilience of each system and the enforcement of common policies. The Continuous Security Paradigm enables independent, decoupled execution while being able to leverage the latest data, and one that enables real-time decisions without huge availability and performance requirements. It also enables independent services to be good citizens of a larger network that can both help other services make good decisions and be a part of a common trust topology.

Managing a Continuous Security Paradigm-based Network

Even though each node operates independently in terms of the decisions it makes, your organization needs to centrally manage the trust topology between various nodes and the policies that you need to comply with within each application or system (e.g., within each node). A centralized management system can use the control plane to set the rules. This is different from a central point of control for each access decision. At the same time, each node is free to dynamically modulate the trust it places in systems it receives data from, based on the quality of signals it receives from them. Diagrammatically, this can be represented as follows:

In the diagram above, all types of systems, including SaaS apps, cloud infrastructure, custom apps, and APIs, follow the same continuous security paradigm. 

• All of them consume signals from other systems, make access decisions for themselves, and selectively convey signals to other systems. This is the new “signals plane” of asynchronous communication that is disjoint from the data plane or the control plane
• An organization would, of course, need to manage trust between various systems (internal or external) and would need to set org-wide contextual rules. That is provided by the control plane described by the long rectangle at the top of the diagram.
• Finally, the systems need to respond to inline requests from the client, regardless of whether the client is a robotic principal or an end-user. Access decisions need to be made for each one of these requests. This is the data plane.

Looking Ahead: The Continuous Security Paradigm in Practice

Where do we begin?

The CSP includes components that may be within your control (such as custom apps) and some that you will need support from (e.g. SaaS apps). However, keeping this paradigm in mind as you build out your strategy is key. You might find solutions that help you realize parts of this picture, and you can influence others in moving to support this architecture. For instance, building out a signals plane by adopting the OpenID Shared Signals Framework can help build out the context for your existing components – whether they are SaaS apps or custom apps.

Use Cases

The big picture here offers a way for cybersecurity and identity practitioners to think about securing systems and services in a way that supports real-time considerations. In our next blog post, we’ll break this down and discuss specific use cases where continuous security paradigms can be used today and the standards that already support this model.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

Authors

Atul Tulshibagwale is the CTO of SGNL, a company backed by Microsoft and Cisco and founded by ex-Googlers that helps enterprises mitigate damage from identity breaches. Named in the Okta “Identity 25”, Atul is a federated identity pioneer and the inventor of the Continuous Access Evaluation Protocol (CAEP). He was previously at Google, where his seminal blog post kicked-off the industry-wide movement that culminated in the OpenID Foundation’s Shared Signals working group, which he co-chairs. Atul is also a Corporate Board Member of the OpenID Foundation. His leadership in developing and promoting SSF and CAEP, the critical zero-trust standards, has been influential in their widespread adoption. Apple, Okta, Cisco, and others have announced support for these standards. Previously, Atul was a co-founder and the CEO of Trustgenix, a federated identity pioneer that was acquired by HP. Trustgenix contributed to the development of federated identity standards such as SAML 2.0 and the Liberty Alliance Framework.

Sean O’Dell is a Senior Staff Security Engineer spanning both Consumer and Workforce IAM at The Walt Disney Company. He is a co-chair of the Shared Signals Working Group in the OpenID Foundation and has been on podcasts covering identity security and written about the subject…with more coming soon. He is a technical leader and trusted technical advisor to executives at The Walt Disney Company where he has been instrumental in both Workforce and Consumer IAM strategy over the past 10 years covering security, product, engineering, implementation, and architecture while also acting as a principal advisor in the same capacity for key mergers and acquisitions helping to shape overall company decisions and direction. His vision, leadership, and implementation expertise are helping to promote and drive the adoption of both SSF and CAEP overall in the industry. His current focus around identity security is zero standing privilege, next-gen authorization, ITDR, shared signals, CAEP, behavioral analysis, data science, identity data…all of the continuous aspects of identity security.

The post The Continuous Security Paradigm appeared first on IDPro.