+1 to have a consistency of defining claims. We have a claim [1] which saying the word "verify email" and need to extra care on the claim name and it's good claim URI self explain the usage of it. Any particular reason to use userstore claim (http://wso2.org/claims/emailaddress.verificationPending) here without using identity claim? Introducing map attributes in the existing LDAP, AD is not something easy.
[1] http://wso2.org/claims/identity/verifyEmail Thanks Godwin On Tue, Jan 21, 2020 at 7:28 AM Malithi Edirisinghe <malit...@wso2.com> wrote: > > > On Mon, Jan 20, 2020 at 5:09 PM Ruwan Abeykoon <ruw...@wso2.com> wrote: > >> 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" >> > > +1. > @Dewni Weeraman <de...@wso2.com> , as this binds to the "emailaddress" ( > http://wso2.org/claims/emailaddress) claim right now, I think we can have > it as "emailaddress.verificationPending" ( > http://wso2.org/claims/emailaddress.verificationPending). > > So that it properly reflects for which claim verification is pending. > > >> 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 >> >> > 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 > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Godwin Amila Shrimal | Technical Lead | WSO2 Inc. (m) +44 744 466 3849 | (w) +44 203 696 6510 | (e) god...@wso2.com <http://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
