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 <[email protected]> wrote: > > > On Sat, Jan 18, 2020 at 6:18 PM Johann Nallathamby <[email protected]> > 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 <[email protected]> >> wrote: >> >>> Hi Johann, >>> >>> On Wed, Jan 8, 2020 at 4:49 AM Ajanthan Balachandran <[email protected]> >>> 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) [email protected] >>> 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) [email protected] >> [image: Signature.jpg] >> > > > -- > *Malithi Edirisinghe* | Technical Lead | WSO2 Inc. > (m) +94 718176807 | (w) +94 11 214 5345 | (e) [email protected] > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Dewni Weeraman | Software Engineer | WSO2 Inc. (m) +94 077 2979049 | (e) [email protected] <[email protected]> <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
