Great, Warren!! I believe that FIDO2 may be recommended on the BCP. But, first we need an agnostic/generic grant-type to this flow.
Em ter., 15 de ago. de 2023 às 15:35, Warren Parad <wparad= 40rhosys...@dmarc.ietf.org> escreveu: > 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
