Hi All, I think those are valid points, but they can be better addressed on identity management forums like idsa or idpro.
https://www.idsalliance.org/ https://idpro.org/ On Mon, Aug 9, 2021 at 5:55 PM Warren Parad <wparad= [email protected]> wrote: > 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 >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
