“In the first post in this series, I framed discovery as a broader systems problem.”

The challenge is not simply that search engines need to be better. Search is useful for public, indexed information, but discovery reaches much further than that. It is about how people and systems determine what exists, where it lives, whether it is relevant, whether it is usable, and whether it should be visible in the first place. When discovery moves into digital identity, search engines hardly enter the picture. No one is typing a query into a search box to find the right credential for a verifier request, the right identity provider for a federated login, or the right authorization server metadata for a client. At least, I sincerely hope not. The discovery work is happening inside user interfaces, metadata documents, wallets, browsers, federation rules, protocol flows, trust lists, and account systems.

The phrase I keep coming back to is governed matching: matching the right identity-related thing to the right request under the right rules. That might mean matching a user to an identity provider, an identifier to an account, a client to metadata, a verifier request to a credential, or a credential to a trust policy. The matching is not purely technical because the rules are not purely technical. They include privacy expectations, usability constraints, business requirements, federation policy, trust frameworks, legal obligations, and whatever fragile compromise made it through the last standards call.

That is where identity discovery gets interesting. And by interesting, I mean this is where the diagrams start lying to us. On a clean architecture slide, identity discovery can look like a tidy routing problem. The user needs access to a service. The service needs to know where to send the user. The protocol handles the rest. Everyone is happy, the arrows are obedient, and no one has to admit how often the user has no idea which button to click. Reality, as usual, is less cooperative.

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

Finding the right door

For many of us, identity discovery first became familiar through federation. In research and education federation, the problem was often framed as helping the user find their home institution or identity provider. The user was trying to access a service. The service did not authenticate the user directly. Instead, it needed to know where to send the user so their own institution could handle authentication. This was the world of “Where Are You From?” services, SAML federation, and institutional discovery pages. It was also the world of users staring at a long list of organizations, wondering whether they should choose the university, the medical school, the library, the hospital, the research institute, or that one institutional name no one has used conversationally since 1997. Good times.

This is where SeamlessAccess belongs in the story. SeamlessAccess is one of the current practical expressions of this work, focused on making federated access to scholarly resources smoother for users while still respecting privacy and institutional identity. It sits at a useful intersection: research and education federation on one side, scholarly publishing access on the other. That matters because, for the user, those are rarely separate problems. The user does not wake up in the morning thinking, “Today I would like to experience an elegant identity provider discovery flow.” The user wants the article, dataset, tool, service, or platform they came for. If the identity path is confusing, discovery has failed from the user’s point of view even if every protocol component is behaving exactly as specified.

That is one of the recurring lessons of identity discovery: the technical flow can succeed while the human experience fails. It is also where governance shows up early. Which identity providers appear in the discovery interface? Which ones are hidden by default? How are institutions named? Are logos used? Are previous choices remembered? Who operates the discovery service? What does the service learn about the user’s institutional affiliations? Can a service provider filter which identity providers are shown? Those questions are part of the discovery problem, not decoration around it. A user-facing discovery service has to balance findability, privacy, operator trust, institutional representation, and the very real risk that the user gives up before reaching the resource.

The NASCAR problem never really went away

Federated login has another familiar discovery problem: too many buttons. If a site supports several external identity providers, the login page can start to look like a race car covered in logos. Google. Apple. Facebook. Microsoft. GitHub. Institutional login. Email link. Username and password. Maybe a government ID provider. Maybe something specific to the industry. I have nothing against options. I have many against option piles.

The “NASCAR problem” has been recognized for years in federated login usability research. One older Google research note on a possible Central Discovery Service described the issue as browser-side identity provider discovery, also known as the NASCAR problem or federated login box problem. The idea being explored was whether a shared and trusted web domain could store a user’s preferred identity providers globally, rather than forcing every relying party to figure it out separately. That proposal is interesting less because it became the answer and more because it shows how quickly a user interface problem turns into a governance problem.

The document described two modes. In one mode, a user’s list of preferred identity providers could be automatically shared with websites so those sites could optimize their login interface. In the more privacy-sensitive mode, the user would choose which identity provider names were shared with a specific relying party. That difference is doing a lot of work. A discovery system that remembers a user’s identity providers can reduce friction. It can also reveal something about that user: their employer, university, email provider, country, professional affiliations, health system, bank, child’s school, or government service provider. The convenience is real. The leakage is also real.

The same Google note asked who would operate such a Central Discovery Service, observing that the technical complexity might be simple but the domain would need to be well trusted and would enforce a whitelist of trusted identity providers. That is another recurring lesson of identity discovery: the entity running the discovery layer is not neutral just because the code is boring. Sometimes the hardest part of discovery is deciding who gets to maintain the map.

CIAM makes discovery a business problem

Customer Identity and Access Management gives us another version of the same pattern. In workforce IAM, an organization usually has a bounded population and a few systems that are treated as authoritative. Human resources systems, contractor systems, directories, and access governance tools may not be perfect, but there is usually a known institutional frame. CIAM is different. The population is public-facing, the user may be unknown or only partially known, and the identity flow sits directly in the path of digital engagement.

In his IDPro article introducing Customer Identity and Access Management, Ian Glazer describes CIAM as focused on registration, authentication, and authorization services for individuals or entities receiving or purchasing services from an organization. He also draws a useful contrast between workforce IAM, which often focuses on delivering the right access to the right people at the right place and time, and CIAM, which also has to deliver the right experience. That experience matters. If registration is confusing, people abandon it. If sign-in is painful, people call support or leave. If account recovery is weak, people get locked out or attackers get in. If social login choices are confusing, users create duplicate accounts or choose the wrong path.

Discovery failure looks like friction

CIAM discovery failures rarely introduce themselves as “discovery failures.” They appear as abandoned registrations, failed logins, duplicate accounts, support calls, password resets, and users giving up before they reach the thing they came for. Ian’s article points out that CIAM stakeholders care about engagement, reduced friction, and loyalty, and it names abandoned account sign-ups, failed logins, support calls, and password reset rates as signs of friction.

In practice, that friction often traces back to a matching problem. Is this person new or returning? Which identifier did they use before? Should this social login connect to an existing account? Which recovery path is safe enough and usable enough? Which profile record is current? Which channel should be trusted for this interaction? The user is not trying to debug your identity architecture. The user is trying to get back to whatever they came to do. When they say, “I can’t find my account,” they are usually describing the symptom, not the architecture problem underneath it.

Profile, credential, account, relationship

CIAM also gives us a useful reminder that identity systems handle several different kinds of identity-related information, and those things should not be casually collapsed. A profile is a collection of attributes about a person. A credential is how that person authenticates to a system. An identifier is the string the system uses to refer to an account or record. Consent records capture what the person agreed to. Preferences capture choices about communication, topics, or experience. Account state may live in one place, profile data in another, customer support history somewhere else, and marketing data in a system nobody in identity should touch without adult supervision. I am only partly joking.

Ian makes the point that profile data may exist in many systems across an organization. A CIAM stack may gather and store some of that data, but that does not mean the identity team owns all profile data or that the CIAM profile is the only representation of the customer. That matters for discovery. When a returning user shows up, what exactly is the system trying to discover? The user’s credential? Their account? Their profile? Their customer record? Their consent state? Their entitlement? Their existing session? Their relationship to an organization? Their relationship to a partner organization? Those are related. They are not interchangeable.

This is one reason “just let the user log in” can become a much larger design problem. The user may have an email/password account, a passkey, a social login, and a customer support record that predates all of them. The organization may have a CRM profile, a marketing profile, an e-commerce record, a loyalty record, and a CIAM profile. Some of those records may be linked. Some may be stale. Some may be wrong. Some may refer to the same human. Some may not. Identity discovery in CIAM often means discovering the right relationship at the right moment without asking the user to complete an archaeological survey of their own past choices.

Metadata can help, within limits

So far, we have been talking mostly about user-facing discovery. Identity discovery also happens between systems. This is where .well-known URIs, OpenID Connect Discovery, OAuth Authorization Server Metadata, and OAuth Protected Resource Metadata fit into the story. The broad idea is straightforward: systems need predictable ways to find machine-readable metadata. Instead of hard-coding every endpoint, capability, key location, and supported feature by hand, a client can retrieve a metadata document from a known location and learn how to interact with a service.

The pattern and the payload

It helps to separate the pattern from the specific uses of the pattern. .well-known is the predictable location pattern. Specifications such as OpenID Connect Discovery, OAuth Authorization Server Metadata, and OAuth Protected Resource Metadata define particular metadata documents that can be found through that pattern. OpenID Connect Discovery defines a mechanism for a relying party to discover the user’s OpenID Provider and obtain information needed to interact with it, including OAuth endpoint locations. OAuth Authorization Server Metadata does something similar for OAuth authorization servers. OAuth Protected Resource Metadata extends the metadata pattern to protected resources.

A lookup is still only a lookup

This is useful—very useful—but it has boundaries. .well-known helps when you already know which origin to ask. It helps a client find metadata at a predictable location, reduces configuration burden, and makes systems more interoperable. It does not, by itself, answer every identity discovery question. If the problem is “where does this known issuer publish its configuration?” then .well-known may be exactly the right tool. If the problem is “which identity provider should this person use?” or “which wallet contains the right credential?” then we are in a different part of the discovery problem.

This is where I start twitching when every discovery conversation turns into “couldn’t we just use DNS?” or “couldn’t we just use .well-known?” Maybe. Sometimes. For the right slice of the problem. A predictable metadata location gives systems a place to ask. It does not decide whether the answer is appropriate, trusted, private, sufficient, or safe to use. A successful metadata lookup is still only a lookup.

Wallets make discovery multidimensional

Digital wallets and credentials make the problem even more interesting, though the vocabulary needs care. In older federation flows, a simplified version of the discovery question might be: where should the user authenticate? In a wallet-mediated credential flow, discovery quickly turns into matching and validation. A verifier may need proof of age, affiliation, professional status, residency, employment, authorization, or some other claim. The user may have multiple wallets. Each wallet may hold different credentials. Those credentials may use different credential formats. They may have been issued by different entities. They may contain similar claims with different names, semantics, assurance levels, or disclosure properties.

So what is being discovered? The wallet? The credential? The issuer? The claim? The verifier’s requirements? The user’s preferred disclosure path? The browser-mediated handoff? The trust list that says which issuers are acceptable? The answer depends on which part of the flow you are staring at, which is precisely why the problem is hard.

The W3C Digital Credentials API is relevant here because it introduces a user-agent-mediated API for presentation and issuance of digital credentials, designed to be credential-format agnostic. OpenID for Verifiable Presentations defines a mechanism for requesting and presenting credentials. The Digital Credentials Query Language (DCQL) provides ways for verifiers to express what they are asking for. The standards work here is active, and the ecosystem is still sorting out how much belongs in the browser, the wallet, the verifier request, the trust framework, and the user experience. I would be wary of any explanation that makes this look more settled than it is.

Discovery, matching, and validation

The shape of the problem is already clear, though. A verifier expresses what it needs. The holder-side software determines what might satisfy the request. The user decides whether to disclose. The verifier validates what comes back and decides whether it is acceptable. Somewhere in that flow, the system has to determine what exists, what matches, what can be shown, what should be hidden, what the user can understand, and what the verifier is allowed to rely on.

When existing is not enough

A credential can exist and still fail to satisfy a request. The issuer may not be trusted. The credential format may not be accepted. The claim may be semantically close but not quite right. The credential may be expired or revoked. The wallet may not be reachable through the available user-agent flow. The user may decline. The verifier may be asking for more than it should. This is progress, certainly, but it is the sort of progress that arrives carrying several new matching problems under one arm.

Discovery has to be authorized

There is one more point that deserves to be named plainly: in identity systems, discovery often has to be authorized before it is useful. Letting the wrong party discover that an account, credential, wallet, relationship, or protected resource exists can itself be a privacy or security failure.

This is not an edge case. User enumeration is a familiar risk in account systems. Wallet and credential enumeration can reveal more about a person than they intended to share. Protected resource discovery can expose information about available services, scopes, or relationships. Institutional discovery can reveal affiliations. Account-linking flows can accidentally confirm that two identifiers belong to the same person. Even a helpful discovery interface can become a leakage point if the wrong party can ask the wrong question.

Conditional findability

That makes identity discovery different from many everyday discovery experiences. In many consumer contexts, more findability feels like better usability. In identity, the better answer is often conditional findability: findable by the right party, for the right purpose, at the right moment, with the right limits. That is why governed matching matters. The governance is not paperwork sprinkled on top after the technical team finishes. It is part of the safety boundary.

What this means in practice

The practical implication is that identity teams should stop asking for “discovery” as if it were a single feature. They should specify the object, the discoverer, the authority model, the privacy constraints, and the failure mode. Otherwise, teams will keep applying the wrong mechanism to the wrong problem and wondering why the user, wallet, client, verifier, or administrator still gets stuck.

Are you trying to help a person find their institution? That is a user experience, federation policy, privacy, and operator trust problem. Are you helping a client find metadata? That is a predictable location and metadata semantics problem, with trust still handled elsewhere. Are you helping a returning customer find the right account path? That is an identifier, account-linking, recovery, fraud, and friction problem. Are you helping a verifier request proof from a wallet? That is a matching, disclosure, validation, and trust framework problem. Are you helping a browser mediate between a website and wallets? That is also a power problem, because mediation determines what becomes visible and usable.

Those are related problems. They need related thinking. They do not all need the same mechanism.

The next layer

Identity discovery started, for many of us, as a familiar login problem. Help the user find the right institution. Avoid the NASCAR page. Remember enough to reduce friction without revealing too much. That problem is still with us, but the identity discovery family has grown. It includes user-facing provider selection, customer account relationship discovery, machine-readable metadata discovery, wallet and credential matching, authorization of discovery itself, and the governance of what should be visible to whom.

The wrong lesson would be to search for one universal discovery mechanism and declare victory. The better lesson is to be precise about which discovery problem is in front of us.

The next post moves from structured identity systems into the messier world of personal account discovery: the accounts, subscriptions, identifiers, and platform relationships people accumulate and then forget. That is where discovery becomes less about protocols and more about the digital life we leave scattered behind us.

📩 If you’d like to be notified of new posts rather than hoping you catch it on social media, I have an option for you! Subscribe to get a notification when new posts go live. No spam, just announcements of new posts. [Subscribe here]

Transcript

In the first discussion in this series, discovery was framed as a broad systems problem.

The challenge is not simply improving search engines. Search works well for public, indexed information. However, discovery extends much further.

Discovery is about determining:

• What exists
• Where it lives
• Whether it is relevant
• Whether it is usable
• Whether it should be visible at all

Once discovery moves into digital identity, search engines are barely part of the equation.

No one is typing a query into a search box to locate:

• The right credential
• The correct identity provider
• The appropriate verifier request
• Authorization server metadata

Instead, identity discovery happens elsewhere.

---

Discovery as Governed Matching

A useful way to think about digital identity discovery is as governed matching.

It involves matching the right identity-related object to the right request under the right rules.

Examples include:

• A user to an identity provider
• An identifier to an account
• A verifier request to a credential
• A credential to a trust policy

Importantly, this matching process is not purely technical.

The rules often include:

• Privacy expectations
• Usability requirements
• Business constraints
• Federation policies
• Trust frameworks
• Governance decisions

As a result, identity discovery quickly becomes more complicated than a routing problem.

---

Why Architecture Diagrams Can Be Misleading

On an architecture slide, identity discovery often appears simple.

The user needs access.

The service needs authentication.

The protocol handles the rest.

Everything looks clean and predictable.

Reality is much less cooperative.

The diagrams rarely capture:

• User confusion
• Governance decisions
• Privacy tradeoffs
• Institutional complexity
• Human behavior

And those factors often determine whether discovery succeeds or fails.

---

The Federation Discovery Problem

For many people, identity discovery first appeared through federation.

The challenge was straightforward:

• A user wants access to a service
• The service does not authenticate directly
• The user must be redirected to the correct institution
• Authentication occurs at the home organization

This became the world of:

• SAML federations
• Institutional discovery services
• “Where Are You From?” interfaces

Unfortunately, users were often presented with enormous lists of organizations and expected to find the correct one.

That experience was rarely elegant.

---

The User Experience Reality

Most users are not interested in identity architecture.

They simply want:

• An article
• A dataset
• A service
• A platform
• A resource they need to access

If reaching that resource becomes confusing, discovery has failed.

This remains one of the most important lessons in digital identity.

A technical flow can succeed perfectly while the user experience fails completely.

---

Where Governance Appears

Discovery is not just about technology.

Governance appears almost immediately.

Organizations must decide:

• Which identity providers appear
• Which are hidden
• How institutions are named
• Whether logos are displayed
• Whether prior selections are remembered
• Who operates the discovery service

These are not secondary questions.

They are central to the discovery problem itself.

Every decision affects:

• Privacy
• Trust
• Findability
• Usability

---

The NASCAR Login Problem

Federated login introduces another familiar challenge.

Sometimes there are simply too many choices.

A login page may display:

• Google
• Apple
• Microsoft
• GitHub
• Facebook
• Institutional login
• Email login
• Username and password

This is often referred to as the NASCAR problem because the interface becomes crowded with options and logos.

While choice can be helpful, excessive choice often creates confusion.

And confusion creates friction.

---

Convenience vs Privacy

Over the years, researchers have explored ways to simplify identity provider discovery.

One approach considered whether a shared service could remember a user’s preferred identity provider.

The potential benefits were obvious:

• Faster login
• Reduced friction
• Better user experience

However, the privacy implications were equally significant.

Such a service could reveal:

• Employers
• Universities
• Government affiliations
• Service providers

This illustrates an important reality.

Discovery systems are never completely neutral.

Someone always controls the map.

---

Customer Identity Discovery Is Different

Customer Identity and Access Management introduces another form of discovery.

Unlike workforce environments, customer-facing systems deal with populations that may be:

• Unknown
• Partially known
• Returning after long periods
• Using multiple identifiers

As a result, discovery becomes deeply intertwined with customer experience.

Organizations must determine:

• Whether a user already exists
• Which account belongs to them
• Which identifier they previously used
• Whether multiple records should be connected

These decisions often occur behind the scenes.

But users feel the consequences immediately.

---

When Discovery Failures Hide in Plain Sight

Customer identity discovery failures rarely appear as discovery failures.

Instead, they appear as:

• Abandoned registrations
• Failed logins
• Duplicate accounts
• Support tickets
• Frustrated users

At first glance, these seem like operational problems.

However, many stem from underlying matching challenges.

The system cannot reliably determine the correct relationship between:

• Users
• Accounts
• Credentials
• Profiles
• Preferences

And that creates friction.

---

Why Identity Data Is More Complex Than It Appears

Modern identity systems manage multiple kinds of information.

These include:

• Profiles
• Credentials
• Identifiers
• Consent records
• Preferences
• Account states

Although related, these elements are not interchangeable.

A profile may live in one system.

A credential may exist elsewhere.

Consent records may reside somewhere entirely different.

This fragmentation creates additional discovery challenges whenever a user returns.

---

Wallets and Credentials Create New Discovery Problems

Digital wallets introduce another layer of complexity.

In traditional federation, discovery often meant finding the correct authentication source.

In credential ecosystems, the challenge becomes much broader.

Questions include:

• Which wallet should be used?
• Which credential satisfies the request?
• Which issuer is trusted?
• Which claims are acceptable?
• What disclosure should occur?

The answers vary depending on the context.

That is exactly what makes wallet discovery difficult.

---

Standards Continue to Evolve

Several standards are shaping credential discovery today.

Examples include:

• W3C Digital Credentials API
• OpenID for Verifiable Presentations
• Digital Credential Query Language

These efforts help establish:

• Credential presentation flows
• Matching requirements
• Browser interactions
• Wallet behavior

However, this ecosystem remains highly active and far from settled.

Anyone describing it as fully mature is oversimplifying the current reality.

---

Discovery Between Systems

So far, the discussion has focused on user-facing discovery.

However, systems also need discovery mechanisms.

This is where technologies such as:

• OpenID Connect Discovery
• OAuth Authorization Server Metadata
• OAuth Protected Resource Metadata
• Well-known URIs

play an important role.

These mechanisms allow systems to locate machine-readable metadata without extensive manual configuration.

That capability improves interoperability significantly.

---

Discovery Is Not Just a Lookup Problem

However, metadata discovery solves only part of the challenge.

Knowing where information exists does not answer:

• Whether it is trustworthy
• Whether it is appropriate
• Whether it should be visible
• Whether it is safe to use

A successful lookup remains only a lookup.

Trust still requires additional evaluation.

And that distinction matters.

---

Discovery Can Become a Privacy Risk

Identity discovery frequently involves sensitive information.

Poorly designed discovery processes can expose:

• User accounts
• Credentials
• Wallet relationships
• Organizational affiliations
• Protected resources

Examples include:

• User enumeration attacks
• Credential enumeration
• Wallet discovery leakage
• Institutional affiliation exposure

In many situations, visibility itself becomes sensitive information.

---

Why Conditional Findability Matters

In consumer environments, greater visibility often seems beneficial.

Identity systems operate differently.

Sometimes the correct outcome is conditional visibility.

Information should be discoverable only:

• By authorized parties
• For legitimate purposes
• Under appropriate controls
• Within defined privacy boundaries

This is why governed matching remains such an important concept.

Discovery without governance can quickly become a security problem.

---

A Better Way to Think About Discovery

Identity teams often ask for “discovery” as though it were a single capability.

In reality, every discovery problem should define:

• What is being discovered
• Who is performing discovery
• What authority they possess
• Which privacy constraints apply
• What failure looks like

Without that clarity, organizations frequently apply the wrong solution to the wrong problem.

---

The Expanding Discovery Landscape

What began as a login problem has evolved significantly.

Today, identity discovery includes:

• Identity provider selection
• Customer account discovery
• Wallet and credential matching
• Metadata discovery
• Discovery authorization
• Governance and visibility controls

Each represents a different discovery challenge.

Treating them as identical creates unnecessary complexity.

---

Looking Ahead

The temptation is to search for one universal discovery mechanism.

That approach is unlikely to succeed.

A better strategy is to identify the specific discovery problem being addressed.

For example:

• Finding a login path
• Locating a credential
• Discovering an account
• Selecting a wallet
• Identifying a trusted source

Each requires different assumptions and different controls.

---

Final Thoughts

Identity discovery is about much more than finding the login button.

It involves governed matching between people, systems, credentials, services, and trust relationships.

As digital identity ecosystems become more sophisticated, discovery becomes increasingly important.

Not only as a technical capability, but also as a question of:

• Governance
• Privacy
• Trust
• Authority
• User experience

Understanding the distinction is critical.

Because once identity enters the picture, discovery is no longer simply about finding something.

It becomes about determining who is allowed to find it, under what conditions, and with what consequences.

---

Conclusion

Discovery remains one of the foundational challenges in digital identity.

Yet there is no single discovery problem.

There are many.

The key is understanding precisely which one you are solving.

Because the success of an identity system often depends less on what it knows and more on whether it can help the right party find the right thing at the right time.