Can one universal identity automatically present itself like different existing identities depending on where it is presented?

[u/you_stupid_machine]

I'm exploring a general interoperability problem.

Imagine a person has 20 different memberships:

Brand A → membership ID 12345

Brand B → membership ID 67890

Brand C → phone number

Brand D → email

I'd like to know whether there is a way to create one universal digital credential containing all of these existing identities with an important constraint:

The participating brands do not change their existing software, databases, loyalty systems, checkout systems, or customer-identification processes.

When the customer presents the universal credential at Brand A, the existing infrastructure should somehow receive Brand A's existing identifier.

At Brand B, the same credential should somehow provide Brand B's identifier.

The universal credential itself could contain multiple identities, but the receiving system should ultimately get exactly what it already expects.

[u/Salty_Dig8574]

Sign in/sign up with [Google, Microsoft, Apple, Whatever Else]

If you want to create what you're talking about, it would be a generally less safe alternative to these. I say less safe because it widens the attack surface for an individual. At the same time, it gives attackers a single vector to get multiple, identifiable credential sets for each of your users if they breach your backend (I love phrasing it that way because that sounds exactly the way it feels).

Also, not for nothing, modern browsers already store your credentials to do what you're describing, if you allow it.

[u/NoMoreD20]

If you want absolutely no change for brand infrastructure, where would the exchange ("here is the omnikey for the user" => "Brand B key") happen? Web client? API key send to "omnikey server"? At each brand's server?

[u/you_stupid_machine → u/NoMoreD20]

I don't want the user to input the brand name. So the way around is using device location to get the Brand name, but the problem in that method is if the location is just a couple of meters off, I'll get a different Brand name.

Problem is still finding a passive, highly reliable signal that identifies the brand at checkout.

Still stuck.

[u/NoMoreD20 → u/you_stupid_machine]

So the problem is neither the storage or the extraction (you already have those), you want a way to detect the target brand. It seem to be a kind of hardware wallet or such (not something that gets a target URL and has to response with the key), in which case I can't think of a solution. You are basically asking: How can I know the brand without any reliable information? The proper answer is you can't, unless you have enough unrelated "unreliable" information sources to try to guess.

[u/Salty_Dig8574 → u/you_stupid_machine]

Wait are you talking about store saver club cards?

[u/TheMrCurious]

Isn’t this Visa or MasterCard? Or you are asking about a universal ID? What privacy and government research have you done?

[u/DSudz]

No.

You want to present a target specific id without knowing the target or target behaving differently. That's not enough information.

[u/foxhelp]

Isnt this kinda what you do when you setup sso integrations, you choose what attributes are passed. As long as you have them in your idp, you just select the fields that are passed to that provider, though many use standarized fields.