Hi Dewni/Malithi, Can we use "*Primary*Email.verificationPending" instead of verificationPending*Primary*Email? In this way we can design a regex for any future pending verifications, like "PrimaryPhone.verificationPending"
Cheers, Ruwan A On Mon, Jan 20, 2020 at 6:20 AM Dewni Weeraman <de...@wso2.com> wrote: > Hi All, > > We will be providing the feature for $subject only in instances where the > user's primary email address is to be updated. When a SCIM update request > for the primary email address is performed, the email address to which the > verification email is sent is represented via the > "verificationPendingPrimaryEmail" attribute in the SCIM response body. > The mutability of "verificationPendingPrimaryEmail" attribute will be set > to *readOnly *so as to prevent direct insertion or modification of this > attribute via a SCIM request. Please note that initially this new attribute > was planned to be named as "verificationPendingEmail", however since the > above feature is only applicable for the primary email address, we have > changed the wording to "verificationPending*Primary*Email" to avoid any > confusion. > > In a scenario where the update request contains claims in addition to the > email address, these other claims will be updated. The HTTP response status > code will be *200 - OK. *As discussed previously in this mail thread the > email claim will not be updated. The new email address is stored against > "verificationPendingPrimaryEmail" claim until the verification process has > been completed successfully. > > Formerly it was decided that the presence of the "verifyEmail" attribute > in the SCIM request is mandatory to trigger the verification. We have > identified that then we will have the complexity of handling update > requests to SCIM /Me endpoint and /Users endpoint separately. The reason > for this is the user can update the email address directly using the /Me > endpoint without triggering an email verification if the request doesn't > contain "verifyEmail" attribute despite the feature being enabled via the > server configuration or not. To avoid this malicious behavior we have > decided that enabling this feature will solely depend on the server > configuration and we will not be checking on the availability of > "verifyEmail" attribute in the SCIM request. > > Thanks, > Dewni > > On Mon, Jan 20, 2020 at 7:29 AM Malithi Edirisinghe <malit...@wso2.com> > wrote: > >> >> >> On Sat, Jan 18, 2020 at 6:18 PM Johann Nallathamby <joh...@wso2.com> >> wrote: >> >>> Hi Malithi, Hi Ajanthan, >>> >>> OK. So if we think like that, how do you propose we do 2FA for security >>> question update? Are you implying that we initiate a SSO flow with higher >>> requested assurance level, so that in IS a step-up authentication is >>> performed and returned back to the service provider, to update his/her >>> security questions? >>> >> >> Yes. And we can do this with conditional auth scripts. >> >> >>> >>> If this is possible with IS then +1 for that. But also I would like to >>> have in the roadmap to do this purely through Rest APIs without ever >>> leaving the service provider. >>> >> >> I think it's subjective. Maybe if it's some email or mobile based >> confirmation it would be fine. But, for advanced options service provider >> will have to manage user interactions if so. What would be the tendency to >> implement such in SP level. >> >> >>> Regards, >>> Johann. >>> >>> On Thu, Jan 16, 2020 at 7:28 AM Malithi Edirisinghe <malit...@wso2.com> >>> wrote: >>> >>>> Hi Johann, >>>> >>>> On Wed, Jan 8, 2020 at 4:49 AM Ajanthan Balachandran <ajant...@wso2.com> >>>> wrote: >>>> >>>>> Hi Johann, >>>>> >>>>> I think here we are talking about two different things. Feel free to >>>>> correct me if I am wrong. >>>>> >>>>> In the first case, we are trying to assert the value of the claims >>>>> provided by the user. In the case of phone number and email claims sending >>>>> verification code does make sense but to assert the first name or last >>>>> name >>>>> sending verification code to email or phone doesn't give enough >>>>> assurance(usually photo ID proof is needed to verify names). >>>>> >>>>> What you are talking about is getting enough assurance level for the >>>>> authenticated user by prompting 2FA to be able to update security >>>>> questions. This should be handled by auth system not the claim >>>>> verification >>>>> system. >>>>> >>>> >>>> I'm under the same understanding with Ajanthan. >>>> It should be a 2FA flow. >>>> >>>> >>>>> >>>>> Thanks, >>>>> Ajanthan. >>>>> >>>>> >>>> Thanks, >>>> Malithi >>>> -- >>>> *Malithi Edirisinghe* | Technical Lead | WSO2 Inc. >>>> (m) +94 718176807 | (w) +94 11 214 5345 | (e) malit...@wso2.com >>>> GET INTEGRATION AGILE >>>> Integration Agility for Digitally Driven Business >>>> >>> >>> >>> -- >>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect >>> | WSO2 Inc. >>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >>> [image: Signature.jpg] >>> >> >> >> -- >> *Malithi Edirisinghe* | Technical Lead | WSO2 Inc. >> (m) +94 718176807 | (w) +94 11 214 5345 | (e) malit...@wso2.com >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Dewni Weeraman | Software Engineer | WSO2 Inc. > (m) +94 077 2979049 | (e) de...@wso2.com <nipu...@wso2.com> > > <http://wso2.com/signature> > > > -- Ruwan Abeykoon | Director/Architect | WSO2 Inc. (w) +947435800 | Email: ruw...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
