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 <mfulz= > [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 <mfulz= >> [email protected]> wrote: >> >>> so just did another test: >>> >>> 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]> <[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 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 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 to [email protected]
