Hi Frederik,
thanks — yes, that’s a very fair and accurate summary, and I think your
separation into those two aspects is exactly right.
To clarify my intent: I am not trying to prevent misbehaving RSs from
doing unsafe things. As you say, a malicious or careless RS can always
choose to ignore any mechanism, just like it can ignore best practices
today. That problem is ultimately social and economic, not technical.
What I am aiming at is the second aspect you described: giving
well-intentioned RSs a standardized, interoperable way to require an
explicit, user-controlled trust binding before accepting assertions from
an AS for account linking (or identity assertion more generally). Today,
the only available signals are UI flow, issuer reputation, or ad-hoc
policies like email matching — all of which are fragile and inconsistent
across deployments.
The proposal is intentionally scoped as:
- Optional and RS-driven (the RS decides when to require it),
- User-mediated (the binding is explicitly created by the subject, not
inferred),
- Protocol-level, but minimal (a capability / binding check, not a new
identity system).
You’re right that this mainly helps defend against ASs that are
malicious or become malicious over time, and to make user journeys more
consistent so users learn what a “real” authorization step looks like.
It does not eliminate risk — it makes a secure choice implementable and
interoperable, instead of purely policy- or UI-based.
Regarding scope: the mechanism could be used only for account linking,
or more broadly for “first assertion from a new issuer” — I’m open on
that point, and that’s something I’d expect to be refined through
discussion.
If you think this framing makes sense, I’m very interested in your
thoughts on whether this fits better as an OAuth/OIDC extension, a BCP,
or perhaps even a security considerations document that formalizes
unsafe default linking patterns.
Cheers,
Matthias
On 12/23/25 4:57 PM, Frederik Krogsdal Jacobsen wrote:
Hi Matthias,
I think there's two separate things being mixed a bit here.
One thing is that the RS can choose to accept authorization from any
AS, even ones that do not have any legitimate identity information.
This is what I understand your example with Facebook in your second
message to involve.
As noted in the previous replies on thread, this cannot really be
prevented (from an end-user perspective) other than by relying on the
reputation of the RS and/or AS, which would eventually be deemed
untrustworthy if they keep doing this.
If you are an RS, you should, as Warren is saying, not accept
arbitrary account linking claims from AS's.
Another thing is that you are proposing a standardized mechanism for
the RS to require explicit consent from the end user before
authorization can take place.
(It's a little unclear to me if this is just supposed to be used when
doing account linking, or for every "new" authorization.)
This would not do anything to prevent the problem of misbehaving RS's,
since they could simply just not implement the mechanism (or fake it).
But it would provide for some standard mechanism by which the RS can
defend itself against malicious AS's, which might make user journeys
better (by making them more similar and thus training end users to
only trust this mechanism).
Again, I think the argument applies that people would eventually stop
trusting AS's that attempt malicious account linking, so the main
benefit is to defend against AS's that have recently become malicious.
I've only briefly skimmed your proposed spec, but it looks like it is
a mechanism for the RS to require end-user approval of the AS in each
authorization.
I'm not really sure where this belongs, but is this a somewhat correct
summary of your proposal?
Cheers,
Frederik
On Tue, 23 Dec 2025 at 16: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 to [email protected]
