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 <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]
