Agreed! Thank you all for the feedback! On Mon, Aug 9, 2021, 5:14 PM Domingos Creado <[email protected]> wrote:
> 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
