Hi Godwin, We will be introducing a new Resident IdP configuration under Account Management Policies to enable this new feature. Also as Malithi has mentioned the 'verifyEmail' temporary claim should also be present in the request to trigger the verification flow.
Thanks, Dewni On Thu, Jan 16, 2020 at 3:10 PM Godwin Shrimal <[email protected]> wrote: > Hi Malithi, > > Thanks for the response. Please see my comment inline below. > > > On Thu, Jan 16, 2020 at 2:13 AM Malithi Edirisinghe <[email protected]> > wrote: > >> Hi Godwin, >> >> On Wed, Jan 15, 2020 at 3:35 PM Godwin Shrimal <[email protected]> wrote: >> >>> Hi All, >>> >>> Sorry for the late to reply to this email. I have following concerns on >>> this feature. >>> >>> 1. Generalizing the feature: I think Johann and Isura also have pointed >>> the same. It looks like this feature is pretty much coupled to the email >>> claim, this same feature can be applied to phone number, IMID etc. So any >>> specific reason why we are not generalizing this and in future we can apply >>> to different scenarios ? >>> >> >> Please refer my reply to Isura's point above. >> We have been having these discussions some time for verifiable claims [1] >> and notifiable claims [2]. >> We don't have these concepts properly in place still. Right now we have >> only email claim. So the focus here, is to fix the feature gap we have >> right now in initiating a verification flow on email update. >> As we proceed we can look into bringing the core feature supporting >> verifiable claims or notifiable claims end to end. >> >> >>> >>> 2. Complexity of applying: I feel following note gives some complexities >>> when comes to the real world scenarios. There may be existing system with >>> existing user base and we need to enable this feature. In such cases, we >>> need to think about user data update, migration etc. So there should not be >>> much overhead on using this feature. Do we have any option for that ? >>> >>> "An admin needs to enable “verifyEmail” claim during user creation to >>> support this feature" >>> >> >> A verification flow can be triggered in request path with 'verifyEmail' >> temporary claim. So that it can be triggered for an existing user base as >> well. >> Yet, our main assumption is when plugging an existing user base, or >> interacting with some other IdP, the claims they bring in are pre-verified. >> Hope I answered your question here. >> > [Godwin: According to the above note ("An admin needs to enable > “verifyEmail” claim during user creation to support this feature"), I > thought we could have enabled Email verification while creating existing > users in the userstore. Is my understanding correct ? If so, how can we > enable this feature in a system we haven't enabled email verification ] > > Thanks > Godwin > >> >> >>> >>> Thanks >>> Godwin >>> >>> On Wed, Jan 15, 2020 at 2:59 AM Dewni Weeraman <[email protected]> wrote: >>> >>>> Hi All, >>>> >>>> Currently, I'm in the final stages of implementing the feature for >>>> email verification when user’s email address is updated. The expected >>>> functionality is achieved by persisting the newly updated email in a newly >>>> configured identity claim: "verificationPendingEmail" claim until the user >>>> verifies the updated email. An email notification will be triggered to the >>>> newly updated email address. Upon successful email account verification, >>>> "emailaddress" claim will be updated with the newly verified email address. >>>> >>>> This feature is invoked via a SCIM 2.0 PATCH request to update the >>>> email address. Please find the sample request and response. >>>> >>>> Request: >>>> >>>> *curl -v -k --user testuser:password -X PATCH -d >>>> '{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[{"op":"add","value":{"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"verifyEmail":"true"}}},{"op":"replace","value":{"emails":[{"primary":true,"value":"[email protected] >>>> <[email protected]>"}]}}]}' --header "Content-Type:application/json" >>>> https://localhost:9443/scim2/Me <https://localhost:9443/scim2/Me>* >>>> >>>> >>>> Response: >>>> >>>> *{"emails":["[email protected] >>>> <[email protected]>"],"meta":{"created":"2020-01-14T07:41:43.662120Z","location":"https://localhost:9443/scim2/Users/0a472190-c862-4f08-aa97-147cff1a714e >>>> <https://localhost:9443/scim2/Users/0a472190-c862-4f08-aa97-147cff1a714e>","lastModified":"2020-01-14T08:34:32.596354Z","resourceType":"User"},"schemas":["urn:ietf:params:scim:schemas:core:2.0:User","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],"roles":[{"type":"default","value":"testrole,Internal/everyone"}],"name":{"givenName":"kim","familyName":"jackson"},"groups":[{"display":"testrole","value":"fea41f11-0160-4fc2-9af5-a9158ed1cc8f","$ref":"https://localhost:9443/scim2/Groups/fea41f11-0160-4fc2-9af5-a9158ed1cc8f >>>> <https://localhost:9443/scim2/Groups/fea41f11-0160-4fc2-9af5-a9158ed1cc8f>"}],"id":"0a472190-c862-4f08-aa97-147cff1a714e","userName":"testuser","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"verificationPendingEmail":"[email protected] >>>> <[email protected]>"}}* >>>> >>>> >>>> As in the above response, the already existing email address will be >>>> displayed with the "emails" attribute while the newly updated email is >>>> displayed with "verificationPendingEmail" attribute. >>>> >>>> As defined in the SCIM specification [1], on successful completion of a >>>> PATCH request, the server returns either *200 - OK* or *204 - No >>>> Content*. In this feature implementation, the HTTP response status >>>> code needs to be *202 -Accepted* to indicate that the request has been >>>> accepted but the processing has not been completed since the updated email >>>> is not verified. Therefore we are currently having concerns regarding the >>>> recommended HTTP status code to be returned with the SCIM response. >>>> >>>> Your input regarding the HTTP status code on this matter is highly >>>> appreciated. Also, I have sent an email to the SCIM public mailing list >>>> regarding our concern on the recommended approach to be followed to achieve >>>> this use case which requires a verifiable claim to be updated. >>>> >>>> [1] https://tools.ietf.org/html/rfc7644#section-3.5.2 >>>> >>>> Kind regards, >>>> Dewni Weeraman >>>> >>>> On Wed, Jan 8, 2020 at 4:50 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. >>>>> >>>>> Thanks, >>>>> Ajanthan. >>>>> >>>>> _______________________________________________ >>>>> 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> >>>> >>>> >>>> >>> >>> -- >>> Godwin Amila Shrimal | Technical Lead | WSO2 Inc. >>> (m) +44 744 466 3849 | (w) +44 203 696 6510 | (e) [email protected] >>> <http://wso2.com/signature> >>> >> >> 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 >> > > > -- > Godwin Amila Shrimal | Technical Lead | WSO2 Inc. > (m) +44 744 466 3849 | (w) +44 203 696 6510 | (e) [email protected] > <http://wso2.com/signature> > -- 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
