Re: [Architecture] [IS][PET] X509 certificates as IS Authenticator

2016-02-04 Thread Prabath Siriwardana
Yes.. basically the objective here is to enable clientAuth for a webapp.. Thanks & regards, -Prabath On Wed, Feb 3, 2016 at 9:52 AM, Rajjaz Mohammed wrote: > Hi Dimuthu, > > @prabath/johan/malaka please correct me if I’m wrong. > in the last meeting with prabath, johan and

Re: [Architecture] [MSF4j] Creating an archetype for a microservice

2016-02-04 Thread Afkham Azeez
This doc has to go to the README.md file in the archetype dir On Thu, Feb 4, 2016 at 9:13 PM, Manuri Amaya Perera wrote: > Hi Azeez, > > I have sent the PR[1]. And please find the documentation here[2]. > > [1] https://github.com/wso2/msf4j/pull/124 > [2] >

[Architecture] Option-text and Unbounded table support in Store

2016-02-04 Thread Chandana Napagoda
Hi All, Currently, we are displaying all the asset level fields (attributes) on the publisher side, and version and name attribute only in the Store. The decision to display all the of the available fields in the Store asset details page depends on the end user business requirements. In most of

Re: [Architecture] [MSF4j] Creating an archetype for a microservice

2016-02-04 Thread Imesh Gunaratne
Thanks Aruna for the answers! On Thu, Feb 4, 2016 at 10:10 AM, Manuri Amaya Perera wrote: > Hi Imesh, > > Aruna has explained the answers to your questions. > Also you can find the previous discussion on creating maven archetypes for > a generic osgi bundle and a carbon

Re: [Architecture] [MSF4j] Creating an archetype for a microservice

2016-02-04 Thread Manuri Amaya Perera
Hi Azeez, I have sent the PR[1]. And please find the documentation here[2]. [1] https://github.com/wso2/msf4j/pull/124 [2] https://docs.google.com/a/wso2.com/document/d/1A5iS6JxbqVuazFwe_EVKeuaXiwCVzOoYOUlA7LSPTPY/edit?usp=sharing Thank you. On Thu, Feb 4, 2016 at 8:40 AM, Manuri Amaya Perera

Re: [Architecture] [MSF4j] Creating an archetype for a microservice

2016-02-04 Thread Kishanthan Thangarajah
Need some improvements to this PR. Let's add "//TODO" to all four methods along with "Implementation for HTTP <> request" as the comment. And as the class level comment for "Microservice" class, let's point to the getting started guide - https://github.com/wso2/msf4j#getting-started, so that the

Re: [Architecture] Moving the OAuth 2.0 Dynamic Client Registration(DCR) feature to WSO2 Identity Server

2016-02-04 Thread Nuwan Dias
Hi Tharika, Have you decided on the security of this endpoint? Thanks, NuwanD. On Thu, Feb 4, 2016 at 9:52 PM, Tharika Madurapperuma wrote: > Hi All, > > We are planning of $subject. > > In some use cases, it is desirable or necessary to allow OAuth clients to > obtain

Re: [Architecture] Moving the OAuth 2.0 Dynamic Client Registration(DCR) feature to WSO2 Identity Server

2016-02-04 Thread Roshan Wijesena
Hi Tharika, +1. Have you thought about a way to fetch/update a DCR application? There is a way you can achieve this by providing an access_token and registration URL upon DCR registration. So then users can persist that access_token and URL and can be used in future in order to edit the DCR

[Architecture] Moving the OAuth 2.0 Dynamic Client Registration(DCR) feature to WSO2 Identity Server

2016-02-04 Thread Tharika Madurapperuma
Hi All, We are planning of $subject. In some use cases, it is desirable or necessary to allow OAuth clients to obtain authorization from an authorization server without the two parties having previously interacted. Therefore in order for the authorization server to accurately represent to end

Re: [Architecture] [MSF4j] Creating an archetype for a microservice

2016-02-04 Thread Lahiru Sandaruwan
Hi Manuri, I think it is better to separately explain the dynamic parameters user can change(project group id, version etc), when they build the project from Archetype. Also, we can mention, for what the example is for? "Building your own project from the WSO2 MSF4J archetype". Thanks. On Thu,

Re: [Architecture] Moving the OAuth 2.0 Dynamic Client Registration(DCR) feature to WSO2 Identity Server

2016-02-04 Thread Amila De Silva
Hi Tharika, Since *"**saasApp"* is not a common parameter as per the spec, you might have to emphasise the usage of it. Just noticed that in the excerpt you've provided request is sent to a resource named oauthdcr. Better if we can name it as /regsiter to show the conformity with the spec. On