I definitely see that there is room for a potential attack depending on the internal implementation. Wouldn't that be only relevant internally to the auth server though? Would adding a feature flag to the discovery document or visibility into configuration help reduce the attack surface? Perhaps, I would need to see the explicit vulnerability and how it would be potentially mitigated. From my uninformed perspective it seems like trying to protect users against a phishing attack that uses a malicious auth server to emulate an honest one, though I could be missing something critical.
Any additional information would be appreciated. - Warren Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Mon, Aug 9, 2021 at 10:44 PM Kevat Shah <[email protected]> wrote: > @[email protected] - Using forgot password and registration verification > links or codes could be used as vectors of attack. > > One possible point of insecurity that I have seen is this: after a user > verifies their code or link, they are often sent to another page where they > enter more information (such as additional user information or new > passwords). The user isn't supposed to be authenticated at this step, and > yet the application must know who the user is. > > How do we confirm the user's identity without authenticating them for > these steps? > > This is the driving factor (the "why") for this ask. > > @[email protected] - I agree. Which channels should we use to > discuss this issue? > > - Kevat > > On Mon, Aug 9, 2021, 4:17 PM Warren Parad <[email protected]> wrote: > >> I think it would be prudent to potentially ask *why?* What problem is >> necessary to be solved by discussing/standardizing these particular >> features? There could be, but without understanding, knowing how best to >> tackle it is a challenging conversation without the right context. >> >> Warren Parad >> >> Founder, CTO >> Secure your user data with IAM authorization as a service. Implement >> Authress <https://authress.io/>. >> >> >> On Mon, Aug 9, 2021 at 10:15 PM Kevat Shah <[email protected]> wrote: >> >>> How would that work? Would we need to work with W3C to ensure conformity >>> of standards? >>> >>> On Mon, Aug 9, 2021, 4:11 PM <[email protected]> wrote: >>> >>>> Although the IETF has been involved in Best Commercial Practices (BCP) >>>> (see https://www.ietf.org/rfc/bcp-index.txt ) which I think was the >>>> subject of Kevat’s original email. >>>> >>>> >>>> >>>> So perhaps this is a subject matter that could co-exist in both the >>>> IETF and W3C? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:* OAuth <[email protected]> *On Behalf Of *Tim Cappalli >>>> *Sent:* Monday, August 9, 2021 4:06 PM >>>> *To:* [email protected] >>>> *Cc:* [email protected] >>>> *Subject:* Re: [OAUTH-WG] Specifications for Identity Providers >>>> >>>> >>>> >>>> I don't think there is explicit ownership, but generally password and >>>> magic link type "stuff" happens in W3C. >>>> >>>> >>>> >>>> There are existing work efforts around standardizing password reset >>>> endpoint discovery, password complexity schemas, etc. >>>> ------------------------------ >>>> >>>> *From:* Kevat Shah <[email protected]> >>>> *Sent:* Monday, August 9, 2021 16:03 >>>> *To:* Tim Cappalli <[email protected]> >>>> *Cc:* [email protected] <[email protected]> >>>> *Subject:* Re: [OAUTH-WG] Specifications for Identity Providers >>>> >>>> >>>> >>>> You don't often get email from [email protected]. Learn why this is >>>> important <http://aka.ms/LearnAboutSenderIdentification> >>>> >>>> That's a good point. Is it fair to assume that W3C owns the standards >>>> for most (if not all) standards related to Identity Providers? Or does it >>>> make sense for IETF to start setting these standards in cases where W3C >>>> standards don't exist? >>>> >>>> >>>> >>>> - Kevat >>>> >>>> On Mon, Aug 9, 2021, 2:56 PM Tim Cappalli <[email protected]> >>>> wrote: >>>> >>>> I believe this topic would be more W3C scope, not IETF. >>>> >>>> >>>> >>>> tim >>>> ------------------------------ >>>> >>>> *From:* OAuth <[email protected]> on behalf of Kevat Shah < >>>> [email protected]> >>>> *Sent:* Sunday, August 8, 2021 16:37 >>>> *To:* [email protected] <[email protected]> >>>> *Subject:* [OAUTH-WG] Specifications for Identity Providers >>>> >>>> >>>> >>>> Some people who received this message don't often get email from >>>> [email protected]. Learn why this is important >>>> <http://aka.ms/LearnAboutSenderIdentification> >>>> >>>> I propose that we expand upon specific functionality provided by >>>> Identity Providers (IdPs) and tasks handled by them. >>>> >>>> >>>> >>>> To start with, there should be clear specifications for various >>>> functionalities that IdPs provide such as: >>>> >>>> >>>> >>>> - Email verification on registration >>>> >>>> - Specifications regarding "forgot password" functionality >>>> >>>> - Specifications regarding "resest password" functionality for users >>>> that are logged in >>>> >>>> >>>> >>>> >>>> >>>> These specifications only pertain to Identity Providers, and allow an >>>> industry-wide set of rules that each Identity Provider must follow. The >>>> purpose of doing so would be to standardize various frequently used and >>>> implemented flows that are secure and widely reusable. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Some problems that would be addressed by these specifications would be: >>>> >>>> >>>> >>>> - How to securely implement functionality where a user is sent a link >>>> to verify their email address >>>> >>>> >>>> >>>> - How to securely implement functionality where a user is sent a >>>> verification code to verify their email address >>>> >>>> >>>> >>>> - How to securely implement functionality where a user is sent a link >>>> to reset their password >>>> >>>> >>>> >>>> - How to securely implement functionality where a user is sent a >>>> verification code to reset their password >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
