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]
