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]
