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 ?
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"
Thanks
Godwin
On Wed, Jan 15, 2020 at 2:59 AM Dewni Weeraman <de...@wso2.com> 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":"jack...@abc.com
> <jack...@abc.com>"}]}}]}' --header "Content-Type:application/json"
> https://localhost:9443/scim2/Me <https://localhost:9443/scim2/Me>*
>
>
> Response:
>
> *{"emails":["kim.jack...@gmail.com
> <kim.jack...@gmail.com>"],"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":"jack...@abc.com
> <jack...@abc.com>"}}*
>
>
> 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 <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.
>>
>> Thanks,
>> Ajanthan.
>>
>> _______________________________________________
>> 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>
>
>
>
--
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
