Hi Warren,
I agree with you on the descriptive level: today, account linking
decisions are entirely an RS concern, regardless of whether assertions
come from OAuth, OIDC, SAML, or any other protocol. The secure default
is indeed to treat identities from different issuers (or protocols) as
unrelated, and any automatic linking is an RS risk decision.
Where I think we still differ is on whether that necessarily makes this
non-standardizable. The fact that RSs currently invent ad-hoc policies
(“email match”, “first login wins”, etc.) does not mean this space is
inherently outside standards — it means there is no interoperable,
user-centric primitive to express issuer authorization at the subject
level. Today the only “signal” is UI flow and issuer assertions, which
are explicitly not bound to a user-controlled trust decision.
I am not arguing that standards should decide when two identities are
the same user. I am arguing that standards could provide a normative,
optional mechanism that allows an RS to require an explicit
user-provisioned trust binding before accepting an AS assertion for
account linkage. That does not remove RS responsibility; it makes a
secure choice implementable in a consistent way, instead of relying on
fragile heuristics. If the right framing is BCP or operational guidance
rather than a core protocol change, I am fully open to that — my goal is
to make the risk explicit and constrain unsafe defaults, not to redefine
identity.
Best regards,
Matthias
On 12/23/25 4:41 PM, Warren Parad wrote:
I'm not sure why you are stuck on OpenID/OAuth. Imagine an RS that
receives SAML grants from two separate IdPs. It's the same problem.
How does one decide that a user that came from two different protocols
is the same user. Ultimately this is 100% an RS concern, because only
the RS can decide that it is the same user. The secure thing to do is
assume that it is never the same user. An RS that decides that a user
from two different AS ones that might even have two different
protocols is outside the scope of all protocols, it's a business
decision. And like all business decisions it's outside the scope of
standards.
The RS, and only the RS decides what makes sense. Whether or not to
risk AS impersonation of a user identity is a risk RS take on if they
want to automatically link.
I'm not sure why we are making this more complex than it is. In
reality, all account linking practices are unsafe by design, some of
them on more unsafe than others. OAuth already provides all the
guidance necessary for an RS to make the necessary decisions. If you
believe that RS are having trouble making the right decision because
of missing attributes at the protocol level, then that's something
that should be added to the spec, but I don't think we are saying that.
On Tue, Dec 23, 2025, 15:33 Matthias Fulz
<[email protected]> wrote:
Ok Warren,
let me try to say it in another way:
OAuth absolutely is a protocol about how a client/resource server
can accept an Authorization Server’s assertions under a defined
security model (issuer, redirect binding, tokens, client
authentication, etc.). What it does not standardize is a
user-controlled, interoperable primitive for “issuer
authorization” at the subject/identifier level.
That’s exactly why this becomes protocol-relevant: today every RS
invents its own ad-hoc policy (“auto-link by email”, “first-login
wins”, “just trust the issuer if email matches”), and those
choices silently create cross-site impersonation/namespace-capture
risk. Calling it “100% RS-side” is describing the current state —
it doesn’t mean there is no missing standard mechanism.
My concrete point is simple: provide a standardized hook/extension
so an RS can require an explicit user-provisioned trust binding
(secret/public key/capability) for (subject, issuer[, RS]) before
accepting issuer assertions. Without such a binding, login MUST
fail. This makes the “RS is responsible” requirement implementable
and interoperable, instead of relying on fragile UI expectations
like “the user clicked the button”.
If this list isn’t the right venue, could you point me to the
right one to discuss a protocol-level extension/BCP that
constrains unsafe account-linking practices in OAuth/OIDC deployments?
BR,
Matthias
On 12/23/25 4:25 PM, Warren Parad wrote:
This isn't an OAuth problem, so this isn't an appropriate place
to discuss this topic. If something is 100% on the RS side, then
it is very clear, that it isn't protocol related.
On Tue, Dec 23, 2025, 15:16 Matthias Fulz
<[email protected]> wrote:
Thats what I try to do:
https://www.ietf.org/archive/id/draft-fulz-oauth-trust-binding-00.txt
And sorry than for my rant I really didn't get the point that
the core problem itself was understood.
And yes it is 100% on the RS side, that's why I'm pointing
directly into the core protocol as technical solution to
circumvent the whole "RS is responsible" for trust.
Think about this approach when the protocol would just say:
You must use cryptographic safe hashes and every RS could
decide what that means for itself ;)
On 12/23/25 4:09 PM, Warren Parad wrote:
Matthias, the problem isn't that it can't be seen. Everyone
already understands the core problem.
The issue that you don't seem to get is that there is no
change to the standard that would cause providers to do the
right thing. This isn't about interoperability between a
Replying Party and the Resource Server, it is 100% an issue
on the RS application side. It has nothing to do with protocols.
Please take a step back and fully think through a concrete
suggestion. Right now saying "it must support this" is
unhelpful, at least provide a concrete implementation
suggestion that works at a protocol level.
On Tue, Dec 23, 2025, 15:02 Matthias Fulz
<[email protected]> wrote:
so just did another test:
heise.de <http://heise.de> -> google login -> nothing to
confirm at heise site that I BY MYSELF DID ALLOW THAT.
All only at google site:
We're using the following data, which is send to third
party....
-> Please explain me now where the part is that I MUST
CLICK this button and not Google or any other identity
"authority" can just do it without my consent?
If it would be enforced at least there should be some
sort of email (like for any email registration) from the
RS (heise) to the mail send from the provider to confirm
that the user really want it.
And yeah that's again the point: If I would use some
mail provider and email confirmation would be the
"solution" it would help nothing as they would have
access to that as well.
That's why I try to say the whole time: THERE MUST BE
some sort of independent IDENTITY OWNER!!! trust grant
enforcement.
Ae. on first login I could enter a own email that is not
related to the identity provider and the RS MUST send a
verification link to this email and this email will be
the core account id.
There are many easy solutions if the problem will be
realized. And I really can't understand how this can't
be seen.....
On 12/23/25 3:43 PM, Matthias Fulz wrote:
Ok than please explain me, where in the protocol itself
is the part that it is impossible without that "click"
to impersonate by just saying to the RS here it is?
Don't get me wrong if that's really integrated I was
wrong and it's all fine, but I can't see it.
Further tell me please how I can take control of like
FB (if I would have an account there) just registering
my user on any site that is providing login via, where
I do not have an account?
Sorry it's all comming back to the point that the
identity owner itself is out of scope.
On 12/23/25 3:25 PM, Michael Sweet wrote:
Matthias,
On Dec 23, 2025, at 9:14 AM, Matthias Fulz
<[email protected]>
<mailto:[email protected]> wrote:
The problem is again you miss the main point:
it's not about issues with trust handling. It's all
about MISSING TRUST GRANTING of the Identity owner
(USER) itself.
Again think about the following:
I've an account at service-cool-stuff with my mail
[email protected] + pw -> ok
service-cool-stuff enables login via Facebook ->
oauth, etc. ok
I DO NOT HAVE ANY FACEBOOK RELATION!!!!!!
Facebook says ok here is the login for
[email protected] signed by us -> service-cool-stuff
trusts -> login valid POINT.
Where is the part that I BY MYSELF have ever said
that Facebook is allowed to identify FOR ME ?????
Facebook validates that you have access to your email
account. They even make you setup a FB account to use
the login via Facebook and authorize using a password,
passkey, etc.
Moreover, the RS had to be configured to provide login
via Facebook, and you (the user) had to click on it to
start the authorization process. If you don't want to
authorize via FB, then don't click that button.
________________________
Michael Sweet
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
