Hi Janak, Shouldn't the [POST] claim-verification/validate and [POST] claim-verification/confirm be a single step (ex: [POST] claim-verification/verify). If additional customization is required, it would be just overriding one method.
WDYT? Best Regards, Vidura Nanayakkara On Thu, Feb 14, 2019 at 3:37 PM Janak Amarasena <ja...@wso2.com> wrote: > Hi All, > > [Update] > > The endpoints of the API was modified and now the following endpoints will > be used. > > 1. [POST] *claim-verification/init-verification *: Endpoint to initiate > the claim verification process. > 2. [POST] *claim-**verification**/**validate *: Endpoint to validate the > claim value. > 3. [POST] *claim-**verification**/**confirm *: Endpoint to confirm the > claim value. This endpoint is optional and will only be used depending on > whether further external validation is required. If not necessary the > validation process can be ended from the /validate endpoint. > 4. [POST] *claim-**verification**/revoke* : Endpoint to cancel the claim > verification process. > > You can find the *swagger doc* related to the API from here[1]. > > The feature will consist of 3 layers. > 1. The API layer - Which exposes the functionality of the service for > external use. > 2. The internal service layer - The actual service which will handle > operations related to confirmation codes, DB transactions. > 3. The Verifiers - Multiple pluggable components that will perform process > initiation(sending notifications) and validation of the claim value. Anyone > will be able to extend a common interface and write a verifier. > > > To give a bit more context; > > - Initially an admin will have to mark which claims need to be > verified, currently, it will be done by adding a claim metadata property. > - When a value for a verifiable claim is added/modified it will not be > stored in the userstore till the value is verified(Which will be done > through the provided API). The verification process will be triggered > depending on the Verifier used to verify the claim. The sent claim value > will be stored temporarily in a separate table which will be introduced > with this feature. > - When user details are retrieved, if there are pending claim > verifications available those claims will be also sent by adding a > prefix(configurable) to the claim name. For an example, if there is a > pending verification for "http://wso2.org/claims/emailaddress";, the " > http://wso2.org/claims/emailaddress"; claim will be sent with the value > that is already in the userstore and " > http://wso2.org/claims/pending-emailaddress"; claim will also be sent > with the changed emailaddress which is still pending verification. The > prefix "pending" will be configurable by an admin and will be a > reserved prefix which cannot be used for claim naming. Service providers > will have the ability to configure whether they want to receive claims that > are having pending verifications. > > > [1] - > https://gist.github.com/janakamarasena/4f37244758e3854d28f1b08f3bd36f6e > > Thank you, > Best Regards, > > Janak > > On Wed, Jan 23, 2019 at 10:39 AM Vihanga Liyanage <viha...@wso2.com> > wrote: > >> OK, thanks for the clarification, Janak. >> >> On Wed, Jan 23, 2019 at 10:28 AM Janak Amarasena <ja...@wso2.com> wrote: >> >>> Hi Vihanga, >>> >>> By default, no claims will be required for verification and an admin >>> user will decide which claims needs verification according to their use >>> case. Ideally how this will happen is we will have a property for a claim >>> where the admin user can mark whether that claim needs verification or >>> not through the management console. This part is not addressed in this >>> implementation and I will only be focusing on the API which will be used >>> for the verification process. >>> >>> Best Regards, >>> Janak >>> >>> On Tue, Jan 22, 2019 at 11:36 PM Vihanga Liyanage <viha...@wso2.com> >>> wrote: >>> >>>> Hi Janak, >>>> >>>> AFAIU, We don't need to verify all claim changes for a particular user. >>>> For example, we can consider the address of the user. Are we planning to >>>> filter out these claims or add a default verification to all claim changes? >>>> >>>> Regards, >>>> Vihanga. >>>> >>>> On Mon, Jan 21, 2019 at 7:41 PM Janak Amarasena <ja...@wso2.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am currently working on creating a claim verification API which will >>>>> be used to verify user claims. The plan is to implement the API in a >>>>> generic manner where any claim that requires verification will be able to >>>>> use the API. And implement the code in a way where an interface can be >>>>> extended and write a custom implementation which will be used for >>>>> specific claim type verifications as not all claims can be verified in the >>>>> same manner. As an example, a username change would require an >>>>> email confirmation whereas a mobile number change would require a >>>>> confirmation code sent to the mobile phone. >>>>> >>>>> The following endpoints will be available. >>>>> 1. [POST] *claim-verification/ *: Endpoint to initiate the claim >>>>> verification process. >>>>> 2. [POST] *claim-**verification**/**validate *: Endpoint to validate >>>>> the claim value. >>>>> 3. [POST] *claim-**verification**/**confirm *: Endpoint to confirm >>>>> the claim value. >>>>> 4. [GET] *claim-**verification**/**pending-verification *: Endpoint >>>>> to lookup pending claim verifications for a user. >>>>> >>>>> You can find a work in progress *swagger doc* related to the API from >>>>> here[1]. >>>>> >>>>> As an example the following diagram shows the flow of how the API >>>>> would be used for changing the username claim of the user. >>>>> >>>>> [image: no title.png] >>>>> >>>>> >>>>> The introduction of the API will also require the introduction of a >>>>> new table to the database for holding the claim values until the >>>>> verification process is completed. This table will contain the following >>>>> attributes; ID, USER_ID, CLAIM_ID, CLAIM_VALUE, VERIFICATION_STATE >>>>> >>>>> >>>>> [1] - >>>>> https://gist.github.com/janakamarasena/4f37244758e3854d28f1b08f3bd36f6e >>>>> >>>>> >>>>> Any thoughts and suggestions in this regard are highly appreciated. >>>>> >>>>> Thank you, >>>>> Best Regards, >>>>> -- >>>>> *Janak Amarasena* >>>>> >>>>> Software Engineer >>>>> >>>>> Email: ja...@wso2.com >>>>> >>>>> Mobile: +94777764144 >>>>> >>>>> Web: https://wso2.com >>>>> >>>>> >>>>> <http://wso2.com/signature> >>>>> >>>> >>>> >>>> -- >>>> >>>> Vihanga Liyanage >>>> >>>> Software Engineer | WS*O₂* Inc. >>>> >>>> M : +*94710124103* | http://wso2.com >>>> >>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>> >>> >>> >>> -- >>> *Janak Amarasena* >>> >>> Software Engineer >>> >>> Email: ja...@wso2.com >>> >>> Mobile: +94777764144 >>> >>> Web: https://wso2.com >>> >>> >>> <http://wso2.com/signature> >>> >> >> >> -- >> >> Vihanga Liyanage >> >> Software Engineer | WS*O₂* Inc. >> >> M : +*94710124103* | http://wso2.com >> >> [image: http://wso2.com/signature] <http://wso2.com/signature> >> > > > -- > *Janak Amarasena* > > Software Engineer > > Email: ja...@wso2.com > > Mobile: +94777764144 > > Web: https://wso2.com > > > <http://wso2.com/signature> > -- Vidura Nanayakkara Senior Software Engineer WSO2, Inc. http://wso2.com <http://wso2.com/>- lean . enterprise . middleware Mobile : +94 (0) 717 919277
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
