+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 <[email protected]> wrote: > > > On Mon, Jan 20, 2020 at 5:09 PM Ruwan Abeykoon <[email protected]> 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 <[email protected]> , 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 <[email protected]> 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 <[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> >>> >>> >>> >> >> -- >> Ruwan Abeykoon | Director/Architect | WSO2 Inc. >> (w) +947435800 | Email: [email protected] >> >> > 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 > _______________________________________________ > Architecture mailing list > [email protected] > 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) [email protected] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
