Hi Malithi,
Thanks for the response. Please see my comment inline below.
On Thu, Jan 16, 2020 at 2:13 AM Malithi Edirisinghe <malit...@wso2.com>
wrote:
> Hi Godwin,
>
> On Wed, Jan 15, 2020 at 3:35 PM Godwin Shrimal <god...@wso2.com> 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 <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>
>>
>
> Thanks,
> Malithi
> --
> *Malithi Edirisinghe* | Technical Lead | WSO2 Inc.
> (m) +94 718176807 | (w) +94 11 214 5345 | (e) malit...@wso2.com
> 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) god...@wso2.com
<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
