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>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
