Hi All, The "emailaddress.verificationPending" ( http://wso2.org/identity/claims/emailaddress.verificationPending) claim suggests a boolean value instead of the actual email value. Therefore we will modify the claim name as "emailaddress.pendingValue" ( http://wso2.org/identity/claims/emailaddress.pendingValue) to avoid any confusion.
As discussed previously, we will be providing the verification on update functionality for the "emailaddress" (http://wso2.org/claims/emailaddress) claim for now. However, we have planned to extend this functionality for other claims such as "emails.work" (http://wso2.org/claims/emails.work) and "emails.home" (http://wso2.org/claims/emails.home) in the future. Therefore it is important to have a proper format when representing these verification pending claims in the SCIM response. The ideal solution is to have a "pendingValue" for each of these claims. Please find the sample request and response. Request: *curl -v -k --user admin:admin -X PATCH -d '{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[ {"op":"replace","value":{"emails":[{"primary":true,"value":"[email protected] <[email protected]>"}]}}]}' --header "Content-Type:application/json" https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109 <https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109>* Response: *{"emails":["[email protected] <[email protected]>"],"meta":{"created":"2020-01-28T05:13:13.992017Z","location":"https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109 <https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109>","lastModified":"2020-01-28T06:04:36.421652Z","resourceType":"User"},"nickName":"dewni1","schemas":["urn:ietf:params:scim:schemas:core:2.0:User","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],"roles":[{"type":"default","value":"Internal/everyone"}],"name":{"givenName":"dewni","familyName":"jackson"},"id":"705cc75d-2640-4c3d-9848-e055a9eb6109","userName":"dewnitest","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"emails":[{"pendingValue":"[email protected] <[email protected]>"}]}}* When we extend the feature to support verification of other claims such as " emails.work" in the future, the SCIM 2.0 response should be as below. Response: *{"emails":["[email protected] <[email protected]>", **{"type":"work","value":"[email protected] <[email protected]>"},{"type":"home","value":"[email protected] <[email protected]>"}**],"meta":{"created":"2020-01-28T05:13:13.992017Z","location":"https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109 <https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109>","lastModified":"2020-01-28T06:04:36.421652Z","resourceType":"User"},"nickName":"dewni1","schemas":["urn:ietf:params:scim:schemas:core:2.0:User","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],"roles":[{"type":"default","value":"Internal/everyone"}],"name":{"givenName":"dewni","familyName":"jackson"},"id":"705cc75d-2640-4c3d-9848-e055a9eb6109","userName":"dewnitest","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"emails":[{"pendingValue":"[email protected] <[email protected]>"},{"type":"work","**pendingValue**":"[email protected] <[email protected]>"},{"type":"home","**pendingValue**":"[email protected] <[email protected]>"}]}}* Kind regards, Dewni -- Dewni Weeraman | Software Engineer | WSO2 Inc. (m) +94 077 2979049 | (e) [email protected] <[email protected]> <http://wso2.com/signature> On Tue, Jan 21, 2020 at 5:50 PM Godwin Shrimal <[email protected]> wrote: > +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 > -- 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
