Let me try that differently, I posit that it might be impossible to secure this in a way that would prevent a different Relying Party from impersonating the user if we only use details *about* the user. However, we do know that using FIDO2 the user can secure communication with the AS, in a way that prevents impersonation.
With that, would it make sense for us to standardize the communication with the AS in a way that operationalizes FIDO2? On Tue, Aug 15, 2023 at 8:28 PM Rodrigo Speller <rspeller= 40primosti.com...@dmarc.ietf.org> wrote: > It could be an internal implementation like any part of OAuth could be, > but from the OAuth perspective, the intent was to create a new Grant Type, > that is not mandatory, but part of the framework. So, this Grant Type > standardizes the generic flow to the AS to obtain the authorization > evidence token from the user and transmit it to the client application. > Probably, the documentation will specify a new grant_type, query parameters > and token response properties. > > And, a standard helps to concern a mature and interoperable approach to > resolve this problem. > > I believe that the final document will be a Grant Type specification, but > a BCP may be used to define practices to operate the keys on some cenarios, > like browsers, native apps, soon. > > I predict some possibilities about the user providing some encrypted > personal data embedded on the authorization evidence token directly to the > client too. But it is out of scope for now. > > I don't have this ready. I'm only answering this group about this > possibility, but I can work with the group about this. > > > Em ter., 15 de ago. de 2023 às 14:59, Warren Parad <wparad= > 40rhosys...@dmarc.ietf.org> escreveu: > >> I think the problem here for me is that lack of clarity of how this >> problem could be better constrained at the protocol level. As far as I can >> see, albeit naively, the problem is purely an internal implementation >> detail. Is that not the case? Is there really something missing in the >> grants that would encourage AS to do the right thing? If so, can you share, >> because I'm not seeing it. >> >> That being said, even if it is an implementation detail, that doesn't >> mean there couldn't be some sort of BCP. >> >> On Tue, Aug 15, 2023 at 7:42 PM Rodrigo Speller <rspeller= >> 40primosti.com...@dmarc.ietf.org> wrote: >> >>> I read all the comments carefully while flying through Brazil, and I >>> confess that my reasoning from the beginning tended to say that the OAuth >>> trust model is “as is” and that the main point of the trust relationship is >>> between the AS and the RO (in this case, a user). >>> >>> At various times, while reading, I agreed that Matthias' question was >>> about a problem that would not fit directly into the OAuth Framework, as I >>> understood that the central point in question was authentication and not >>> authorization. But I refused to accept that my point of view would be >>> correct due to the avalanche of exposed reasoning that contributed to my >>> understanding and that even so, Matthias insisted on making himself >>> understood by different approaches, leading to believe that he understood >>> the answers, but still did not was convinced that we had understood this >>> problem in essence. >>> >>> So, during the flight, I reflected on Matthias' insistence: "What could >>> we be missing?" Brilliantly, I think Matthias raised a very important and >>> fixable point: “That the user MUST allow the connection on both sides on >>> the client and on the provider.” >>> >>> As is known here, OAuth 2.0 is not a ready-to-use protocol, but a >>> framework that is constantly evolving, it is specified by multiple RFCs and >>> its main implementation is the OpenID Connect 1.0 layer, which is also >>> under development. I say this because I believe the solution to this point >>> raised by Matthias would result in a Zero-Trust Authorization Grant with >>> great value to the protocol, as it would reinforce user authorization so >>> that the AS could authorize client applications. >>> >>> In this grant type, the AS would ask the user to sign evidence tokens to >>> authorize client application access in the authentication/consent phase. Of >>> course, this flow would require some restrictions to maintain a high degree >>> of security, such as: Generation and storage of user signature keys; Form >>> of registration of the signature verification key with the AS; Transport of >>> authorization evidence to the client application; Transporting the evidence >>> token signature verification key to the client application; etc; >>> >>> I believe that a Zero-Trust Grant Type with a model similar to the one >>> above would be very useful for Web 3, financial applications (FAPI / Open >>> Banking), etc. It would also encourage the use of private keys to >>> authenticate users in these environments, making room for the signing of >>> operational tokens in the future (out of scope). >>> >>> Therefore, I ask Matthias to validate and complement, if possible, my >>> point of view. And I invite this group to start an effort to draft this >>> Grant Type with me. >>> >>> >>> Em qui., 10 de ago. de 2023 às 22:21, Michael Jones < >>> michael_b_jo...@hotmail.com> escreveu: >>> >>>> I HIGHLY recommend the authoritative blog post on the subject “OAuth >>>> 2.0 and Sign-In”, written by a dear friend to many of us, Vittorio >>>> Bertocci, just over a decade ago. While Microsoft took it down, it lives >>>> on in the Wayback Machine at >>>> http://web.archive.org/web/20130105031040/http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx >>>> <http://web.archive.org/web/20130105031040/http:/blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx>. >>>> It authoritatively covers much of the ground in our current discussion. >>>> >>>> >>>> >>>> Read and enjoy! >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Dick Hardt >>>> *Sent:* Thursday, August 10, 2023 5:46 PM >>>> *To:* Matthias Fulz <mf...@olznet.de> >>>> *Cc:* oauth@ietf.org >>>> *Subject:* Re: [OAUTH-WG] OAuth Trust model >>>> >>>> >>>> >>>> Sorry -- I have not read this thread in depth, so if you have another >>>> crisp example, please send. >>>> >>>> >>>> >>>> Your description sounds like an identity problem and not an >>>> authorization problem. OAuth solves the latter, and it is a feature that >>>> the RS does need to know the client, only that the client is authorized. >>>> >>>> >>>> >>>> To fit that into your analogy, anyone the school deems authorized to >>>> pick up the kid is authorized to pick up the kid. If you don't like how the >>>> school decides that, don't send your kid to that school, or work to change >>>> the school's policy. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Aug 10, 2023 at 4:41 PM Matthias Fulz <mf...@olznet.de> wrote: >>>> >>>> I'm running out of ideas to get the point explained... >>>> >>>> Ok let's try it from an abstract view: >>>> >>>> Think about a school where your kid is allowed to get picked up by a >>>> legitimated list of persons -> ok >>>> >>>> Now think about the school saying I'm trusting a third party about >>>> identifying any person on that list, without asking the person about that >>>> this third party is allowed to identify this person. >>>> >>>> The problem is, that by design the person who's identity is to be >>>> verified has no control about what AS is allowed by the site to verify the >>>> identity. >>>> >>>> >>>> >>>> Sorry for that stupid example but I'm really not able to explain the >>>> issue in another way anymore :( >>>> >>>> On 8/11/23 00:02, Dick Hardt wrote: >>>> >>>> This sentence does not make sense to me "which AS is AUTHORIZED at >>>> which RS acting as the user" >>>> >>>> >>>> >>>> The RS server has delegated authorization decisions to the AS >>>> >>>> >>>> >>>> The client is acting as the user >>>> >>>> >>>> >>>> On Thu, Aug 10, 2023 at 2:59 PM Matthias Fulz <mf...@olznet.de> wrote: >>>> >>>> I can follow your point but please try to think from a different >>>> perspective: >>>> >>>> As authorization protocol, how can it not let the user decide which AS >>>> is AUTHORIZED at which RS acting as the user? >>>> >>>> >>>> >>>> On 8/10/23 23:28, Dick Hardt wrote: >>>> >>>> "auth providers" is an extremely confusing term. >>>> >>>> >>>> >>>> OAuth has no involvement in the content an RS provides the client -- >>>> the AS only provides authorization to access the content at the RS. >>>> >>>> >>>> >>>> It is common that the AS and RS are the same entity, but the protocol >>>> is designed to have a separation of concerns so that they are acting >>>> independently. >>>> >>>> >>>> >>>> From what I can understand in your discussion, you are wanting OAuth to >>>> do something it is not designed for. >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Aug 10, 2023 at 2:03 PM Matthias Fulz <mf...@olznet.de> wrote: >>>> >>>> >>>> >>>> On 8/10/23 10:25, Warren Parad wrote: >>>> >>>> You've lost me at this: >>>> >>>> >>>> >>>> Some site, which I'm registered in is trusting some oauth provider I'm >>>> not even knowing about. I'm not registered at this provider. If this >>>> provider is (independent how or from whom) is used in a malicious way, they >>>> can access my account, without my knowledge by sending a valid token >>>> including my email. >>>> >>>> >>>> >>>> Nothing stops a site you are using, registered with your email address, >>>> from just selling your data to a third party, or blanket publishing it >>>> publicly. There is nothing we can do to stop this unless the data we care >>>> about is encrypted on the client side. OAuth doesn't really have anything >>>> to do with it. >>>> >>>> Yes but that's the point: The site itself has to do it. If they are not >>>> willing to it's ok. >>>> >>>> But: With the actual concept using auth providers, even if the the site >>>> is NOT willing to sell it, my account could be accessed by using the >>>> trusted auth provider without the site itself needs to do anything. And the >>>> problem is, that such sites wouldn't be technically forced to use such auth >>>> providers by active permission granting from user side. >>>> >>>> That's the difference I'm trying to point at. >>>> >>>> Sorry I'm really struggling to explain it in another way (will think >>>> about). >>>> >>>> >>>> >>>> Because it has nothing to do with OAuth, the suggested solution of >>>> course must have a hole with it. And indeed it does. What if the site >>>> offers the token strategy, but then decides to outsource the whole >>>> authentication process to a different third party? We are back at the same >>>> problem again. However it sounds like what you are saying is that there >>>> should be a standardized mechanism for handling the site <=> user token >>>> verification. If we use OAuth terminology that would be: We should allow >>>> *step-up >>>> authentication* to occur solely between the *resource server (RS)* and >>>> the *user agent* without involving the *authorization server (AS)*. >>>> But then who generates the new JWTs? If the AS generates the new one then, >>>> we didn't stop anything. And if the RS generates the new one then actually >>>> the AS isn't needed to do anything. >>>> >>>> No that's not what I was suggesting. >>>> >>>> It's not about excluding the authorization server it's more about a >>>> additional verification, that the user is granting the RS explicit >>>> permission to use the AS on behalf. >>>> >>>> AFAIK the actual situation is the following: >>>> >>>> The site is providing the login via AS and the AS can then on behalf >>>> any user of this site just login. The site can of course implement some >>>> permission granting but that's not required. This is done via signed JWT, >>>> etc. which are verified on the RS side. >>>> >>>> Now my suggestion would be more like adding an additional verification >>>> before the AS can be used: >>>> >>>> *The following is just some rough idea on how to add such verification >>>> in a safe way* >>>> >>>> The RS side will use a signed jwt that will be included into the access >>>> token send from AS to verify that the user has granted permission to use >>>> this AS. >>>> >>>> This could be done automatically during registration, so it wouldn't >>>> break this feature in a way that the RS will create this token during >>>> registration and send it to the AS. The AS will need to include this token >>>> for requests and if this cannot be verified on the RS side it will not be >>>> accepted. >>>> >>>> Further (ae. existing accounts) the user could provide a signed jwt to >>>> the AS and a pub key to the RS. If the jwt cannot be verified than the user >>>> did not granted the permission to use the AS on behalf. >>>> >>>> >>>> >>>> For companies, etc. using RS / AS on premise this could all be >>>> implemented to be done automatically and it would not create any additional >>>> effort on administration side. >>>> >>>> >>>> >>>> And that latter case is actually the reality if we consider these >>>> tokens to be a 2FA mechanism that is managed by the site/resource server. >>>> So I read this as, we should standardize *WebAuthn *communication >>>> between a *user agent* and the *resource server. *That already exists >>>> though, doesn't it? >>>> >>>> Yes and no: Think about the widely used TOTP (ae. github) the Secret >>>> Key is created on the AS side and therefore under full control of it. This >>>> is not helping to protect the user from malicious intents. >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Aug 10, 2023 at 12:59 AM Matthias Fulz <mf...@olznet.de> wrote: >>>> >>>> I'm trying to explain my concern more deeply, please try to follow my >>>> thinking. >>>> >>>> First: Everything you've written is correct and I fully agree. >>>> >>>> But: The difference is: I'm deciding, that I'm using email from xy, I'm >>>> deciding, that I'm using this email to register at some site or anything. >>>> >>>> Anything of these services could be hacked of course, and then they can >>>> use my mail to reset password, use the accounts, etc. >>>> >>>> Now think from the other side: >>>> >>>> Some site, which I'm registered in is trusting some oauth provider I'm >>>> not even knowing about. I'm not registered at this provider. If this >>>> provider is (independent how or from whom) is used in a malicious way, they >>>> can access my account, without my knowledge by sending a valid token >>>> including my email. >>>> >>>> >>>> >>>> I'm not sure how to explain the main concern about this in more detail >>>> and of course I can avoid services providing these type of logins without >>>> my permission, but as said what about the future? >>>> >>>> On 8/10/23 00:40, Warren Parad wrote: >>>> >>>> Let me try that differently, is OAuth more vulnerable than email usage? >>>> If you hacked any email provider that's arguably a bigger goldmine than >>>> just ones protected by oauth. As long as sites are protected by email, >>>> oauth gives a more secure strategy. Most providers that accept email as >>>> authentication allow you to reset your password via email. >>>> >>>> >>>> >>>> Going further, "email is insecure" because providers that send email >>>> can impersonate you. How about telecom companies, they can pretend to send >>>> SMS from you. Or the government, they could issue a new password in your >>>> name and pretend to be you. The horror. >>>> >>>> >>>> >>>> In all seriousness, it's about your threat modal more than anything. >>>> Concerned about your email, then that's your weak point, concern about >>>> oauth, we'll first be concerned about your email, and then you can be >>>> concerned about oauth. >>>> >>>> >>>> >>>> If we assume that everything was on oauth, then there's the question of >>>> why don't providers just implement a FIDO2 compliant strategy. Wouldn't >>>> that solve everything? >>>> >>>> Don't get me wrong: I'm not telling everything is on oauth as far (I'm >>>> not so deep into the protocol) it's acting only as authorization not as >>>> authentication, than it is anyway the wrong point to address this issue. >>>> >>>> But if it would be possible to eliminate this specific issue inside the >>>> protocol directly, it would be the best solution to not even run into this >>>> situation at any later point of time. >>>> >>>> >>>> >>>> As total naive approach I could about something like: >>>> >>>> Client is trusting Provider for user authentication/authorization >>>> >>>> Client must set some random verification token (normally requested / >>>> set by the user) >>>> >>>> User is registering this token under the provider >>>> >>>> Only if this token is valid the token is accepted by the client >>>> >>>> >>>> >>>> If something like this would be included in the protocol itself, it >>>> would be working in all situations like companies because they can control >>>> both sides and generate such tokens automatically >>>> >>>> And yes if the site is working together with the provider than it's >>>> over, but that's exactly the point: Than the target itself must be included >>>> not only the single provider, where the user might not even have an >>>> relationship with. >>>> >>>> >>>> >>>> Further I could think of extended security, by using signed tokens with >>>> user provided public key, so it's technically secured to just fake tokens. >>>> >>>> >>>> >>>> On Thu, Aug 10, 2023 at 12:27 AM Matthias Fulz <mf...@olznet.de> wrote: >>>> >>>> Thank you for the responses so far. >>>> >>>> On 8/9/23 22:20, Warren Parad wrote: >>>> >>>> I can tell you I definitely read it. I actually read it multiple times. >>>> But I don't know what to tell you. The problem you've identified exists, >>>> but that doesn't necessarily mean it is a problem. In a way it is a bit >>>> like, You create a bank account at a bank and you give them all your money. >>>> They then decide to never give it back. >>>> >>>> Yep I know, but the difference is, that I've full control over my >>>> decision to give my money to this bank or not. >>>> >>>> >>>> >>>> While banks are regulated in most countries and things like GitHub are >>>> not, in essence this interaction is based on trust. Of course solutions >>>> like WebAuthn via FIDO2 used as a first party authentication can solve >>>> this, and arguably this is the remit of the entire web3.0 domain. >>>> >>>> >>>> >>>> I don't think anyone would suggest this isn't a problem, just that it >>>> isn't that big of a problem. I think realistically, in order for this >>>> problem to have a closed form solution, it would need to start with a >>>> suggestion on how to solve it, rather than a bunch of us agreeing that it >>>> is. Because right now there doesn't seem to be any fundamental solution >>>> available for this. And honestly, the bigger problem is the digital assets >>>> at risk at the third parties is not due to impersonation, but just general >>>> negligence. GitHub isn't trying to malicious log into my StackOverflow >>>> account, and Google isn't trying to log into my bank. That's because these >>>> organizations have supposedly bound themselves to not grant this ability to >>>> their internal engineers to abuse. And they are spending tons of resources >>>> attempting to stop external attackers. >>>> >>>> >>>> >>>> That being said, it's hard to know if this problem hasn't already >>>> transgressed in the wild. While it is certainly possible, it seems internal >>>> users are more likely to act maliciously on behalf of the user via their >>>> owned data in their own company, rather than attempt to impersonate their >>>> users at third party sites. >>>> >>>> These points are totally correct, but I think also about something like >>>> official Authorities (ae. Patriot Act, etc.) that would definitely be >>>> interested in such things (ok not on me personally), but this is another >>>> topic. >>>> >>>> For me to be more safe, I'm using now a unique mail for Github, etc., >>>> which is sufficient for now, but if you think into the future and >>>> especially about oauth with more than a handful widely used trusted >>>> Providers and that they could be hacked, infiltrated forced to grant >>>> malicious access, etc. Than this could become to a huge problem in no time. >>>> >>>> As example: Think about one widely used trusted provider that's hacked, >>>> or similar. You could access so many accounts on multiple sites, even if >>>> the users are never used this oauth for these sites. >>>> >>>> >>>> >>>> Sorry to insist here, but just because it is not an issue now, I can't >>>> agree that this not a big deal in general. >>>> >>>> I mean in the above scenario even a unique mail wouldn't help because >>>> that could send any mail, they want to these sites. Think about such >>>> provider acting malicious and you would not even HAVE an account at any of >>>> them: every site, that trusts them could be accessed under your account >>>> just by knowing the user identifier, which is in 99% time the mail. >>>> >>>> >>>> >>>> - Matthias >>>> >>>> >>>> >>>> - Warren >>>> >>>> >>>> >>>> On Wed, Aug 9, 2023 at 10:06 PM mfulz <mf...@olznet.de> wrote: >>>> >>>> Anyone read this topic or could tell if there is a better place to >>>> adress this? >>>> >>>> >>>> >>>> Sent from Nine <http://www.9folders.com/> >>>> ------------------------------ >>>> >>>> *Von:* mfulz >>>> *Gesendet:* Sonntag, 16. Juli 2023 03:38 >>>> *An:* oauth@ietf.org >>>> *Betreff:* [OAUTH-WG] OAuth Trust model >>>> >>>> >>>> >>>> >>>> >>>> Hi Together, >>>> >>>> I was thinking about some (at least I see it in that way) problem in >>>> the whole oauth/openid design: >>>> >>>> The problem is the following: >>>> >>>> The user has no control about what providers are accepted by the >>>> clients (websites, etc.) and this opens access to these providers without >>>> any way to protect against that. >>>> >>>> Example: >>>> >>>> I've created an account with email/password login at stackoverflow >>>> >>>> I've created an account with the same email at github >>>> >>>> -> logged out from stackoverflow >>>> >>>> -> logged in via github oauth -> working and connected to the email/pw >>>> account from stackoverflow >>>> >>>> >>>> >>>> Stackoverflow has the possibility to remove the github login now, but >>>> the main problem is, that I would be out of control, that some of these >>>> oauth providers >>>> >>>> (please don't go into the discussion WHY they or anyone should do it) >>>> could access my accounts, when such site would allow them as provider. >>>> >>>> >>>> >>>> In my opionion it would be good to avoid such issues, by including >>>> something in the standard, that the user MUST allow the connection on both >>>> sides on the client >>>> >>>> and on the provider. >>>> >>>> >>>> >>>> Yes for sso without any existing account that's some kind of an issue, >>>> but still it could be added some verification process like sending >>>> confirmation link >>>> >>>> That the user is accepting the oauth provider on the Client side. >>>> >>>> Then the oauth provider would also need access to my emails to access >>>> my account. >>>> >>>> >>>> >>>> Not sure if I'm wrong here but I think my description is correct. >>>> >>>> >>>> >>>> BR, >>>> >>>> Matthias >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
