Thanks. I generally am in favor of mechanisms that can be provided to
RS's as libraries to transfer responsibility to AS's, which it seems
to me that this could be.
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.
There are many circumstances (i.e. any situation where the RS and AS
have a strong and/or legally regulated relationship) where this kind
of mechanism is unnecessary and only introduces additional friction
for the user. Whatever document format this ends up as could easily be
written with considerations for this. Otherwise, I don't have a strong
opinion on this, as I guess it depends on what you are doing with the
authorization as an RS.
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.
Since it requires some standardized communication, I guess at least
the technical part of it would have to be an OAuth/OIDC extension
spec. I think it belongs more in OAuth than OIDC, but I don't have a
strong opinion.
A BCP describing how to do (and especially not do) account linking
could then refer to that spec. I don't know if such a document already
exists somewhere, but I think it would definitely be valuable, even
without the new spec. As others have noted, each RS needs to make
decisions about whether and how they should do account linking. I'm
not an expert on this topic, but if anyone who is would like to
contribute to such a document, I think that would be worthwhile.
Maybe it would be worthwhile to also cross-post a summary of the
proposal to the AB/Connect WG in the OpenID Foundation to get some
more perspectives. You would need to sign up for the mailing list and
sign the contributor agreement for the OpenID Foundation first (which
is free and easy).
Cheers,
Frederik
On Tue, 23 Dec 2025 at 17:04, Matthias Fulz <[email protected]> wrote:
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]
