Hi Johann, > > > You might have missed to confirm on this. This is the most important point. > Do you also agree that any requested claim in the request object must be > returned regardless of the scopes we have requested or registered? >
Agreed. I missed this previously. Thanks, On Mon, Jan 29, 2018 at 11:17 AM, Johann Nallathamby <[email protected]> wrote: > Hi Hasanthi, > > On Thu, Jan 25, 2018 at 11:30 AM, Johann Nallathamby <[email protected]> > wrote: > >> Hi Hasanthi, >> >> On Wed, Jan 24, 2018 at 11:14 PM, Hasanthi Purnima Dissanayake < >> [email protected]> wrote: >> >>> Hi Johann, >>> >>> First of all apologies for the late reply :). >>> >>> Hi Hasanthi, >>>> >>>> On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake < >>>> [email protected]> wrote: >>>> >>>>> Hi Johann, >>>>> >>>>> Is there any instance in which IS will throw error to client because >>>>>> it cannot send the claim? >>>>>> >>>>>> Because in the spec it says the following. >>>>>> >>>>>> Note that even if the Claims are not available because the End-User >>>>>> did not authorize their release or they are not present, the >>>>>> Authorization >>>>>> Server MUST NOT generate an error when Claims are not returned, whether >>>>>> they are Essential or Voluntary, unless otherwise specified in the >>>>>> description of the specific claim. >>>>>> >>>>>> So IMO we need to have a property for each claim that says whether we >>>>>> return an error or not. >>>>>> >>>>>> Wdyt? >>>>>> >>>>> >>>>> What I understand from the above is, if a claim is marked as essential >>>>> or voluntary and if the server can not return the claim the flow should >>>>> not >>>>> break and server should not throw an error if it is not specially >>>>> specified >>>>> in the server side. In this scope we don't specify this from server side. >>>>> Though this is not a MUST we can add this as an improvement as it adds a >>>>> value. >>>>> >>>> >>>> So IIUC in any circumstance we don't send an error to client. Correct? >>>> >>>> Yes, we can add that property as an improvement. >>>> >>>>> >>>>> >>>>>>> 2. The claims like "nickname" it will act as a default claim and >>>>>>> will control by both requested scopes and the requested claims. >>>>>>> >>>>>> >>>>>> What do you mean by controlling using requested scope? Do you mean if >>>>>> the client doesn't request at least one scope that includes this claim we >>>>>> won't return that claim? I don't think that is mentioned in the spec. Can >>>>>> you clarify? >>>>>> >>>>> >>>>> The spec does not directly specify how should we treat for the Voluntary >>>>> Claim from the server side. So what we have planned to do is to honour the >>>>> scopes and server level requested claims when returning this claim. >>>>> >>>> >>>> IMO, because the spec doesn't say to do anything special on the OP side >>>> about not being able to release a particular claim (it says not to break >>>> the normal flow), there is nothing special we can differentiate between >>>> essential and voluntary claims. Only thing we may be able to do is, give a >>>> warning to user saying that if s/he doesn't approve an essential claim s/he >>>> won't be able to work with the application smoothly. We can't do anything >>>> beyond that right? >>>> >>>> When you say scopes which scopes are you referring to? Are they the >>>> requested scopes in the request or the defined scopes in the registry? I >>>> fail to understand what scopes have to do with claims in this case. >>>> Following is what I find in spec related to this. >>>> >>> >>> Here what I meant was requested scopes in the request. In this case the >>> request object itself can contain scope values. If there are scopes in the >>> request object , the authorization request scopes will be overriden from >>> those scopes. >>> >> >> That is fine, if that's what the spec says. My concern is not about that. >> My concern is if there is a requested claim in the request object we must >> return it. We don't need check them against scopes. >> > > You might have missed to confirm on this. This is the most important point. > Do you also agree that any requested claim in the request object must be > returned regardless of the scopes we have requested or registered? > > Regards, > Johann. > > >>> >>>> "It is also the only way to request specific combinations of the >>>> standard Claims that cannot be specified using scope values. " >>>> >>>> As I understand if the specific requested OIDC claim, is defined in the >>>> OIDC dialect, the user has a value for that claim and s/he has approved >>>> that claim for the RP, then we can send them to the RP, regardless of >>>> whether it is defined in scope or not. Otherwise we are contradicting the >>>> above statement right? >>>> >>> >>> BTW, the above statement is for 'claim' parameter not for 'request' >>> parameter right? >>> >> >> Yes it is about claim parameter. >> >> >>> If it is related to 'request' parameter as well then I also feel it is >>> wrong to depend on the scopes here. So if we skip checking the requested >>> scope for both voluntary and essential claims, how will be the server >>> response for essential :true (essential), essential:false and null >>> (voluntary) values? >>> >> >> This is what I said. The server response for any kind of claim parameter >> (essential or voluntary) is the same. Any reason to disagree? >> >> Regards, >> Johann. >> >> >>> >>> Thanks, >>> >>> >>> >>> >>> On Wed, Jan 24, 2018 at 9:14 PM, Johann Nallathamby <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Wed, Jan 24, 2018 at 2:12 PM, Farasath Ahamed <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tuesday, January 23, 2018, Johann Nallathamby <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Farasath, >>>>>> >>>>>> On Tue, Jan 23, 2018 at 12:13 PM, Farasath Ahamed <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tuesday, January 23, 2018, Johann Nallathamby <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Hasanthi, >>>>>>>> >>>>>>>> On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Johann, >>>>>>>>> >>>>>>>>> Is there any instance in which IS will throw error to client >>>>>>>>>> because it cannot send the claim? >>>>>>>>>> >>>>>>>>>> Because in the spec it says the following. >>>>>>>>>> >>>>>>>>>> Note that even if the Claims are not available because the >>>>>>>>>> End-User did not authorize their release or they are not present, the >>>>>>>>>> Authorization Server MUST NOT generate an error when Claims are not >>>>>>>>>> returned, whether they are Essential or Voluntary, unless otherwise >>>>>>>>>> specified in the description of the specific claim. >>>>>>>>>> >>>>>>>>>> So IMO we need to have a property for each claim that says >>>>>>>>>> whether we return an error or not. >>>>>>>>>> >>>>>>>>>> Wdyt? >>>>>>>>>> >>>>>>>>> >>>>>>>>> What I understand from the above is, if a claim is marked as >>>>>>>>> essential or voluntary and if the server can not return the claim the >>>>>>>>> flow >>>>>>>>> should not break and server should not throw an error if it is not >>>>>>>>> specially specified in the server side. In this scope we don't >>>>>>>>> specify this >>>>>>>>> from server side. Though this is not a MUST we can add this as an >>>>>>>>> improvement as it adds a value. >>>>>>>>> >>>>>>>> >>>>>>>> So IIUC in any circumstance we don't send an error to client. >>>>>>>> Correct? >>>>>>>> >>>>>>>> Yes, we can add that property as an improvement. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 2. The claims like "nickname" it will act as a default claim and >>>>>>>>>>> will control by both requested scopes and the requested claims. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What do you mean by controlling using requested scope? Do you >>>>>>>>>> mean if the client doesn't request at least one scope that includes >>>>>>>>>> this >>>>>>>>>> claim we won't return that claim? I don't think that is mentioned in >>>>>>>>>> the >>>>>>>>>> spec. Can you clarify? >>>>>>>>>> >>>>>>>>> >>>>>>>>> The spec does not directly specify how should we treat for the >>>>>>>>> Voluntary >>>>>>>>> Claim from the server side. So what we have planned to do is to >>>>>>>>> honour the >>>>>>>>> scopes and server level requested claims when returning this claim. >>>>>>>>> >>>>>>>> >>>>>>>> IMO, because the spec doesn't say to do anything special on the OP >>>>>>>> side about not being able to release a particular claim (it says not to >>>>>>>> break the normal flow), there is nothing special we can differentiate >>>>>>>> between essential and voluntary claims. Only thing we may be able to >>>>>>>> do is, >>>>>>>> give a warning to user saying that if s/he doesn't approve an essential >>>>>>>> claim s/he won't be able to work with the application smoothly. We >>>>>>>> can't do >>>>>>>> anything beyond that right? >>>>>>>> >>>>>>>> When you say scopes which scopes are you referring to? Are they the >>>>>>>> requested scopes in the request or the defined scopes in the registry? >>>>>>>> I >>>>>>>> fail to understand what scopes have to do with claims in this case. >>>>>>>> Following is what I find in spec related to this. >>>>>>>> >>>>>>>> "It is also the only way to request specific combinations of the >>>>>>>> standard Claims that cannot be specified using scope values. " >>>>>>>> >>>>>>>> As I understand if the specific requested OIDC claim, is defined in >>>>>>>> the OIDC dialect, the user has a value for that claim and s/he has >>>>>>>> approved >>>>>>>> that claim for the RP, then we can send them to the RP, regardless of >>>>>>>> whether it is defined in scope or not. Otherwise we are contradicting >>>>>>>> the >>>>>>>> above statement right? >>>>>>>> >>>>>>>> Also regarding requested claims in service provider configuration, >>>>>>>> IIRC we used it as a way to control access to certain claims by service >>>>>>>> providers, which overrides the requested scopes and requested claims. >>>>>>>> *But >>>>>>>> that is only if the requested claims list is not empty in service >>>>>>>> provider >>>>>>>> configuration*. I.e. requested claims in service provider >>>>>>>> configuration must have at least 1 claim. Otherwise what will happen >>>>>>>> is for >>>>>>>> every service provider we need to add all the OIDC claims if they are >>>>>>>> going >>>>>>>> to request claims dynamically, using scopes or requested claims in the >>>>>>>> request. Do I make sense or am I missing something? >>>>>>>> >>>>>>> >>>>>>> In our current implementation requested claims and claims included >>>>>>> in requested scopes act as two filters for user claims sent to service >>>>>>> provider. >>>>>>> >>>>>>> First user claims are filtered by requested claims and then by >>>>>>> claims included in requested scope. So if an SP doesn't have any claims >>>>>>> configured as requested claims then no claims will be sent our in >>>>>>> id_token >>>>>>> or userinfo response. >>>>>>> >>>>>>> From IS 5.2.0 this has been the behaviour. >>>>>>> >>>>>> >>>>>> Thanks for the info. This is not violating anything. But I feel it's >>>>>> a huge pain to configure all the claims as requested claims for all the >>>>>> service providers. I think we have around 25 OIDC claims. And if we have >>>>>> around 10 service providers that means we need to configure 250 claims. >>>>>> >>>>>> I believe we need to improve this. I think for OIDC implementation we >>>>>> can interpret requested claims the way I have mentioned above. I.e. if >>>>>> the >>>>>> list is empty we don't have to restrict anything. We can send all the >>>>>> claims defined under "oidc" scope + requested scopes in request + >>>>>> requested >>>>>> claims in request. If at least one requested claim is defined in SP UI, >>>>>> then we send the intersection of the two. >>>>>> >>>>>> For SAML however it will have to be interpreted differently, because >>>>>> SAML2 doesn't have a way to request specific attributes. So empty list >>>>>> would mean don't send any attributes. >>>>>> >>>>>> Wdyt? >>>>>> >>>>> >>>>> Yes. A totally valid point about the pain the user has to go through >>>>> to configure request claims at Service Provider. It gets even more >>>>> frustrating for the user since he has to find the corresponding claim URI >>>>> in local dialect for each OIDC claim he wants to send out the RP. >>>>> >>>> >>>>> However, handling/interpreting claim handling specific to a protocol >>>>> at Identity Framework level doesn't sound right to me. >>>>> >>>> >>>> Wait, I have a question after reading your reply :). How do we >>>> currently handle claims for OIDC specifically in authentication framework? >>>> Haven't we written any code specific to OIDC by checking the request type? >>>> >>>> >>>>> How about providing an option at Service Provider level to get all >>>>> user claims from Framework? >>>>> >>>> >>>> If we are fine to do UI changes, following will be the best approach I >>>> would suggest. >>>> >>>> 1. In the SP UI, under Claim Configurations, we will have following >>>> options (we may decide to remove something if it doesn't suit). >>>> a. Send requested claims only >>>> b. Send following claims only >>>> c. Send requested claims + following claims >>>> d. Don't send any claims >>>> >>>> 2. Based on the above configuration the inbound authenticator will have >>>> a way to process the request and find out the claims that need to be sent >>>> to the service provider. >>>> >>>> 3. The inbound authenticator will delegate the authentication request >>>> to framework in a protocol neutral manner by specifying the requested >>>> claims. >>>> >>>> 4. Authentication framework retrieves the requested claims and sends it >>>> along with the response to inbound authenticator, and inbound authenticator >>>> will add them to final response and send it to client. >>>> >>>> Regards, >>>> Johann. >>>> >>>> >>>>> >>>>> In a way, this is something you have proposed. The difference is >>>>> rather than interpreting the "no requested claims" for OIDC. We will have >>>>> a >>>>> dedicated option to send all claims that can be used for any protocol. We >>>>> retrieve all non-null user claims and add them to the context with our >>>>> default claim handler implementation. Therefore we won't have any >>>>> additional overhead to retrieve all claims. >>>>> >>>>> Then a user who wants to configure OIDC claims can simply select this >>>>> option and then OIDC scopes to limit claims sent out the RP. >>>>> WDYT? >>>>> >>>>> >>>>> Thanks, >>>>> Farasath >>>>> >>>>> >>>>>> >>>>>> Regards, >>>>>> Johann. >>>>>> >>>>>> >>>>>>>> Regards, >>>>>>>> Johann. >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 23, 2018 at 9:05 AM, Johann Nallathamby < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Hasanthi, >>>>>>>>>> >>>>>>>>>> On Wed, Oct 11, 2017 at 4:35 PM, Hasanthi Purnima Dissanayake < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> In order to support 'Request Object' we need to support two >>>>>>>>>>> parameters. >>>>>>>>>>> 1. request parameter >>>>>>>>>>> 2. request_uri parameter >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *1. request_parameter* >>>>>>>>>>> The purpose of this parameter is for supporting to request some >>>>>>>>>>> claims other than the default Userinfo and IdToken claim set which >>>>>>>>>>> is >>>>>>>>>>> associated with the requested scope. >>>>>>>>>>> >>>>>>>>>>> So if we consider a sample request with above parameter, >>>>>>>>>>> >>>>>>>>>>> https://localhost:9443/oauth2/authorize? >>>>>>>>>>> response_type=code%20id_token >>>>>>>>>>> &client_id=XXXXX >>>>>>>>>>> &redirect_uri=http://localhost:8080/playground >>>>>>>>>>> &scope=openid >>>>>>>>>>> &state=af0ifjsldkj >>>>>>>>>>> &nonce=n-0S6_WzA2Mj >>>>>>>>>>> &request={ >>>>>>>>>>> "iss": "s6BhdRkqt3", >>>>>>>>>>> "aud": "https://server.example.com";, >>>>>>>>>>> "response_type": "code id_token", >>>>>>>>>>> "client_id": "s6BhdRkqt3", >>>>>>>>>>> "redirect_uri": "https://client.example.org/cb";, >>>>>>>>>>> "scope": "openid", >>>>>>>>>>> "state": "af0ifjsldkj", >>>>>>>>>>> "nonce": "n-0S6_WzA2Mj", >>>>>>>>>>> "max_age": 86400, >>>>>>>>>>> >>>>>>>>>>> "claims": { >>>>>>>>>>> "userinfo": { >>>>>>>>>>> "given_name": { >>>>>>>>>>> "essential": true >>>>>>>>>>> }, >>>>>>>>>>> "nickname": null, >>>>>>>>>>> "email": { >>>>>>>>>>> "essential": true >>>>>>>>>>> }, >>>>>>>>>>> >>>>>>>>>>> "id_token": { >>>>>>>>>>> "gender": null, >>>>>>>>>>> "birthdate": { >>>>>>>>>>> "essential": true >>>>>>>>>>> }, >>>>>>>>>>> "acr": { >>>>>>>>>>> "values": [ >>>>>>>>>>> "urn:mace:incommon:iap:silver" >>>>>>>>>>> ] >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The expected behavior of Identity server will be as follows. >>>>>>>>>>> >>>>>>>>>>> 1.Consider the claims "given_name" and "email" which are marked >>>>>>>>>>> as 'essential:true' for 'userinfo' member. Even if they are not >>>>>>>>>>> mapped with >>>>>>>>>>> the openid scope in the registry, if these claims are requested >>>>>>>>>>> claims, >>>>>>>>>>> then 'given_name' and 'email' will be returned from the Userinfo >>>>>>>>>>> endpoint. >>>>>>>>>>> So as a summary the claims which have marked as 'essential : true' >>>>>>>>>>> only get >>>>>>>>>>> controlled by the requested claims and ignore the requested scopes. >>>>>>>>>>> If the >>>>>>>>>>> server can not provide those essential claims there wont be any >>>>>>>>>>> failure or >>>>>>>>>>> error message returning from the server. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is there any instance in which IS will throw error to client >>>>>>>>>> because it cannot send the claim? >>>>>>>>>> >>>>>>>>>> Because in the spec it says the following. >>>>>>>>>> >>>>>>>>>> Note that even if the Claims are not available because the >>>>>>>>>> End-User did not authorize their release or they are not present, the >>>>>>>>>> Authorization Server MUST NOT generate an error when Claims are not >>>>>>>>>> returned, whether they are Essential or Voluntary, unless otherwise >>>>>>>>>> specified in the description of the specific claim. >>>>>>>>>> >>>>>>>>>> So IMO we need to have a property for each claim that says >>>>>>>>>> whether we return an error or not. >>>>>>>>>> >>>>>>>>>> Wdyt? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2. The claims like "nickname" it will act as a default claim and >>>>>>>>>>> will control by both requested scopes and the requested claims. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What do you mean by controlling using requested scope? Do you >>>>>>>>>> mean if the client doesn't request at least one scope that includes >>>>>>>>>> this >>>>>>>>>> claim we won't return that claim? I don't think that is mentioned in >>>>>>>>>> the >>>>>>>>>> spec. Can you clarify? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Johann. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> This behavior is common to the id token as well. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *2. request_uri parameter* >>>>>>>>>>> In this case the url will be a pre-registered url by the RP for >>>>>>>>>>> use at the OP. The reference which is pointed from the url will >>>>>>>>>>> consist the >>>>>>>>>>> relevant jwt. The rationale behind returning claims will be same as >>>>>>>>>>> the >>>>>>>>>>> above in the request parameter. >>>>>>>>>>> >>>>>>>>>>> As we are planning to provide the implementation as a 5.3.0 WUM >>>>>>>>>>> update the 'acr' implementation will be not available there. So if >>>>>>>>>>> 'acr' >>>>>>>>>>> value is requested as an essential claim a pre-define value will be >>>>>>>>>>> returned. >>>>>>>>>>> >>>>>>>>>>> Any suggestion or feedback on the above will be highly >>>>>>>>>>> appreciated. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Hasanthi Dissanayake >>>>>>>>>>> >>>>>>>>>>> Software Engineer | WSO2 >>>>>>>>>>> >>>>>>>>>>> E: [email protected] >>>>>>>>>>> M :0718407133| http://wso2.com <http://wso2.com/> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> *Johann Dilantha Nallathamby* >>>>>>>>>> Senior Lead Solutions Engineer >>>>>>>>>> WSO2, Inc. >>>>>>>>>> lean.enterprise.middleware >>>>>>>>>> >>>>>>>>>> Mobile: *+94 77 7776950* >>>>>>>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>>>>>>>>> <http://www.linkedin.com/in/johann-nallathamby>* >>>>>>>>>> Medium: *https://medium.com/@johann_nallathamby >>>>>>>>>> <https://medium.com/@johann_nallathamby>* >>>>>>>>>> Twitter: *@dj_nallaa* >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Hasanthi Dissanayake >>>>>>>>> >>>>>>>>> Senior Software Engineer | WSO2 >>>>>>>>> >>>>>>>>> E: [email protected] >>>>>>>>> M :0718407133| http://wso2.com <http://wso2.com/> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Johann Dilantha Nallathamby* >>>>>>>> Senior Lead Solutions Engineer >>>>>>>> WSO2, Inc. >>>>>>>> lean.enterprise.middleware >>>>>>>> >>>>>>>> Mobile: *+94 77 7776950* >>>>>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>>>>>>> <http://www.linkedin.com/in/johann-nallathamby>* >>>>>>>> Medium: *https://medium.com/@johann_nallathamby >>>>>>>> <https://medium.com/@johann_nallathamby>* >>>>>>>> Twitter: *@dj_nallaa* >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Farasath Ahamed >>>>>>> Senior Software Engineer, WSO2 Inc.; http://wso2.com >>>>>>> Mobile: +94777603866 >>>>>>> Blog: blog.farazath.com >>>>>>> Twitter: @farazath619 <https://twitter.com/farazath619> >>>>>>> <http://wso2.com/signature> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johann Dilantha Nallathamby* >>>>>> Senior Lead Solutions Engineer >>>>>> WSO2, Inc. >>>>>> lean.enterprise.middleware >>>>>> >>>>>> Mobile: *+94 77 7776950* >>>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>>>>> <http://www.linkedin.com/in/johann-nallathamby>* >>>>>> Medium: *https://medium.com/@johann_nallathamby >>>>>> <https://medium.com/@johann_nallathamby>* >>>>>> Twitter: *@dj_nallaa* >>>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Johann Dilantha Nallathamby* >>>> Senior Lead Solutions Engineer >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile: *+94 77 7776950* >>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>>> <http://www.linkedin.com/in/johann-nallathamby>* >>>> Medium: *https://medium.com/@johann_nallathamby >>>> <https://medium.com/@johann_nallathamby>* >>>> Twitter: *@dj_nallaa* >>>> >>> >>> >>> >>> -- >>> >>> Hasanthi Dissanayake >>> >>> Senior Software Engineer | WSO2 >>> >>> E: [email protected] >>> M :0718407133| http://wso2.com <http://wso2.com/> >>> >> >> >> >> -- >> >> *Johann Dilantha Nallathamby* >> Senior Lead Solutions Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile: *+94 77 7776950* >> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >> <http://www.linkedin.com/in/johann-nallathamby>* >> Medium: *https://medium.com/@johann_nallathamby >> <https://medium.com/@johann_nallathamby>* >> Twitter: *@dj_nallaa* >> > > > > -- > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile: *+94 77 7776950* > LinkedIn: *http://www.linkedin.com/in/johann-nallathamby > <http://www.linkedin.com/in/johann-nallathamby>* > Medium: *https://medium.com/@johann_nallathamby > <https://medium.com/@johann_nallathamby>* > Twitter: *@dj_nallaa* > -- Hasanthi Dissanayake Senior Software Engineer | WSO2 E: [email protected] M :0718407133| http://wso2.com <http://wso2.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
