Re: [Architecture] OpenAPI 3.0 support for API Manager 2.2.0

[Nuwan Dias]

My concern is on the folks who aren’t even aware of the oas version being
used. When someone is creating an api on the UI, they’ll feel as if the SDK
generation has vanished (if we disable it for v3 ones). Therefore it’ll be
better to make v2 the default and provide a warning on the UI regarding
SDKs when switching to 3.0.

On Thu, 25 Jan 2018 at 11:46 am, Thilini Shanika  wrote:

> If someone creates an API from the UI, the default swagger doc will be in
> version 3 right? Can a developer switch back to a 2.0 based definition if
> so?
>
> As per the current implementation, the default version of the generation
> swagger doc is a version 3.0.0 supported doc. But the publisher user can
> selectively decide the supported swagger version, in the advanced option
> provided at starting point of API creation.
>
> Initially, we tried to provide the functionality of switching the API spec
> version in API design phase but then we faced some difficulties to handle
> the swagger doc conversion of 2.0 -> 3.0.0 and 3.0.0 -> 2.0 and we could
> not find any third party library to handle this conversion. We can write a
> conversion for the basic swagger definition we generate underneath, but in
> a case where the user edits the swagger doc via the swagger editor, and
> adds some complex definitions to api doc, then we need to consider them as
> handle those complex definition conversions too.
>
> Further, we tried to maintain two swagger definition objects for OAS 3.0
> and Swagger 2.0.0, and as we perform different operations via API design
> phase, both objects will be updated as per the operation (ie: Adding new
> resource, parameters). Once the user switched the swagger version, the
> requested swagger definition will be loaded as the API's swagger doc. But
> that was not a clean way of handling the conversion so that we decided to
> stick to the current approach of specifying the swagger definition at api
> create staring point.
>
>
>
> [image: Inline image 1]
>
>
>
> On Thu, Jan 25, 2018 at 11:07 AM, Nuwan Dias  wrote:
>
>> If someone creates an API from the UI, the default swagger doc will be in
>> version 3 right? Can a developer switch back to a 2.0 based definition if
>> so?
>>
>> On Thu, 25 Jan 2018 at 9:45 am, Thilini Shanika 
>> wrote:
>>
>>> Hi All,
>>>
>>> We have been supporting client side SDK generation via API Store and API
>>> Store REST APIs, for swagger 2.0 based definitions. But currently, we are
>>> unable to support this particular feature fo OAS 3 based APIs, since the
>>> swagger codegen 3.x version, which is having OAS 3.0.0 support, is not
>>> released yet.
>>>
>>> Thus, shall we disable this functionality for OAS 3 specific APIs?
>>> Basically, we should disable the SDK generation via API Store and REST
>>> APIs, if it is an OAS 3.0.0 based API.
>>>
>>> WDYT?
>>>
>>>
>>> On Wed, Jan 10, 2018 at 10:54 AM, Thilini Shanika 
>>> wrote:
>>>
 @Harsha

 In this case will our swagger console in store compatible with multiple
 swagger versions? How would be the compatibility of swagger library across
 multiple versions that we currently used in the product?

 Yes, it is compatible. We have upgraded Swagger UI to 3.x version,
 which is having support for both Swagger 2.0 and Open API 3.0. Basically,
 the current swagger ui embedded in APIM supports both versions, but we need
 to carefully handle the custom elements that we inject to swagger
 definition before rendering it to API Store ie: gateway environment
 details, security definitions etc (There are differences of specifying API
 endpoints and security definitions Swagger 2.0 and Open API 3.0)


 @Roshan


 Do we have a significant difference between swagger and openAPI?
 According to the
 https://swagger.io/blog/difference-between-swagger-and-openapi/,
 swagger is a tool and openAPI is the spec it self.

 Yes, there are some significant differences between Swagger 2.0 and
 Open API 3.0 spec. Please refer to [1] to have an overview understanding on
 whats net in Open API 3.0. Basically swagger spec has been renamed as
 OpenAPI as it was donated to Linux foundation and technically OpenAPI 3.0
 is the Swagger spec version 3.0. But still, openAPI uses the swagger tools
 ie: Swagger UI, Swagger Editor, Swagger codegen

 Do we need to concern about swagger definition vs openAPI definition,
 rather versions of it?
 Since OpenAPI 3.0 has to be considered as the Swagger 3.0, we need to
 consider the version.

 [1] https://blog.readme.io/an-example-filled-guide-to-swagger-3-2/

 On Wed, Jan 10, 2018 at 4:55 AM, roshan wijesena  wrote:

> Folks,
>
> Do we have a significant difference between swagger and openAPI?
> According to the
> 

[Architecture] Resources for Deploying WSO2 API-M on DC/OS v1.10

[Imesh Gunaratne]

Hi All,

I created resources for deploying WSO2 API-M on DC/OS v1.10:
https://github.com/wso2/dcos-apim/pull/2

This includes three Marathon applications for orchestrating one MySQL
instance, one API-M instance and one API-M Analytics instance. The MySQL
Marathon application is only intended for evaluation purposes, for
enterprise deployments a production ready RDBMS would need to be used.

Moving forward, we need to improve this and support API-M deployment
pattern 1 by adding one more API-M instance and one additional API-M
Analytics instance. Afterwards similar resources need to be created for all
five API-M deployment patterns.

Compared to DC/OS v1.7, I noticed following improvements in DC/OS v1.10:

   - Container to container communication with overlay networking
   - Service discovery with Minuteman
   - Built-in Marathon runtime

Please try this out and let me know your thoughts.

[1] https://docs.mesosphere.com/1.10/
[2] https://github.com/dcos/minuteman

Thanks
Imesh

-- 
*Imesh Gunaratne*
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OpenAPI 3.0 support for API Manager 2.2.0

[Thilini Shanika]

If someone creates an API from the UI, the default swagger doc will be in
version 3 right? Can a developer switch back to a 2.0 based definition if
so?

As per the current implementation, the default version of the generation
swagger doc is a version 3.0.0 supported doc. But the publisher user can
selectively decide the supported swagger version, in the advanced option
provided at starting point of API creation.

Initially, we tried to provide the functionality of switching the API spec
version in API design phase but then we faced some difficulties to handle
the swagger doc conversion of 2.0 -> 3.0.0 and 3.0.0 -> 2.0 and we could
not find any third party library to handle this conversion. We can write a
conversion for the basic swagger definition we generate underneath, but in
a case where the user edits the swagger doc via the swagger editor, and
adds some complex definitions to api doc, then we need to consider them as
handle those complex definition conversions too.

Further, we tried to maintain two swagger definition objects for OAS 3.0
and Swagger 2.0.0, and as we perform different operations via API design
phase, both objects will be updated as per the operation (ie: Adding new
resource, parameters). Once the user switched the swagger version, the
requested swagger definition will be loaded as the API's swagger doc. But
that was not a clean way of handling the conversion so that we decided to
stick to the current approach of specifying the swagger definition at api
create staring point.



[image: Inline image 1]



On Thu, Jan 25, 2018 at 11:07 AM, Nuwan Dias  wrote:

> If someone creates an API from the UI, the default swagger doc will be in
> version 3 right? Can a developer switch back to a 2.0 based definition if
> so?
>
> On Thu, 25 Jan 2018 at 9:45 am, Thilini Shanika  wrote:
>
>> Hi All,
>>
>> We have been supporting client side SDK generation via API Store and API
>> Store REST APIs, for swagger 2.0 based definitions. But currently, we are
>> unable to support this particular feature fo OAS 3 based APIs, since the
>> swagger codegen 3.x version, which is having OAS 3.0.0 support, is not
>> released yet.
>>
>> Thus, shall we disable this functionality for OAS 3 specific APIs?
>> Basically, we should disable the SDK generation via API Store and REST
>> APIs, if it is an OAS 3.0.0 based API.
>>
>> WDYT?
>>
>>
>> On Wed, Jan 10, 2018 at 10:54 AM, Thilini Shanika 
>> wrote:
>>
>>> @Harsha
>>>
>>> In this case will our swagger console in store compatible with multiple
>>> swagger versions? How would be the compatibility of swagger library across
>>> multiple versions that we currently used in the product?
>>>
>>> Yes, it is compatible. We have upgraded Swagger UI to 3.x version, which
>>> is having support for both Swagger 2.0 and Open API 3.0. Basically, the
>>> current swagger ui embedded in APIM supports both versions, but we need to
>>> carefully handle the custom elements that we inject to swagger definition
>>> before rendering it to API Store ie: gateway environment details, security
>>> definitions etc (There are differences of specifying API endpoints and
>>> security definitions Swagger 2.0 and Open API 3.0)
>>>
>>>
>>> @Roshan
>>>
>>>
>>> Do we have a significant difference between swagger and openAPI?
>>> According to the https://swagger.io/blog/difference-between-swagger-
>>> and-openapi/, swagger is a tool and openAPI is the spec it self.
>>>
>>> Yes, there are some significant differences between Swagger 2.0 and Open
>>> API 3.0 spec. Please refer to [1] to have an overview understanding on
>>> whats net in Open API 3.0. Basically swagger spec has been renamed as
>>> OpenAPI as it was donated to Linux foundation and technically OpenAPI 3.0
>>> is the Swagger spec version 3.0. But still, openAPI uses the swagger tools
>>> ie: Swagger UI, Swagger Editor, Swagger codegen
>>>
>>> Do we need to concern about swagger definition vs openAPI definition,
>>> rather versions of it?
>>> Since OpenAPI 3.0 has to be considered as the Swagger 3.0, we need to
>>> consider the version.
>>>
>>> [1] https://blog.readme.io/an-example-filled-guide-to-swagger-3-2/
>>>
>>> On Wed, Jan 10, 2018 at 4:55 AM, roshan wijesena 
>>> wrote:
>>>
 Folks,

 Do we have a significant difference between swagger and openAPI?
 According to the https://swagger.io/blog/difference-between-swagger-
 and-openapi/, swagger is a tool and openAPI is the spec it self.

 Do we need to concern about swagger definition vs openAPI definition,
 rather versions of it?

 Regards
 Roshan



 On Wed, Jan 10, 2018 at 7:25 AM, Harsha Kumara 
 wrote:

>
>
> On Tue, Jan 9, 2018 at 10:57 AM, Thilini Shanika 
> wrote:
>
>> @Bhathiya,
>>
>> Our initial plan was to provide an advanced option for developers to
>> decide the 

Re: [Architecture] OpenAPI 3.0 support for API Manager 2.2.0

[Malintha Amarasinghe]

Hi Nuwan,

On Thu, Jan 25, 2018 at 11:07 AM, Nuwan Dias  wrote:

> If someone creates an API from the UI, the default swagger doc will be in
> version 3 right?
>

SDK generation will need to be disabled for spec 3 APIs. If we make spec 3
default will it be a problem for first time users?



>
> On Thu, 25 Jan 2018 at 9:45 am, Thilini Shanika  wrote:
>
>> Hi All,
>>
>> We have been supporting client side SDK generation via API Store and API
>> Store REST APIs, for swagger 2.0 based definitions. But currently, we are
>> unable to support this particular feature fo OAS 3 based APIs, since the
>> swagger codegen 3.x version, which is having OAS 3.0.0 support, is not
>> released yet.
>>
>> Thus, shall we disable this functionality for OAS 3 specific APIs?
>> Basically, we should disable the SDK generation via API Store and REST
>> APIs, if it is an OAS 3.0.0 based API.
>>
>> WDYT?
>>
>>
>> On Wed, Jan 10, 2018 at 10:54 AM, Thilini Shanika 
>> wrote:
>>
>>> @Harsha
>>>
>>> In this case will our swagger console in store compatible with multiple
>>> swagger versions? How would be the compatibility of swagger library across
>>> multiple versions that we currently used in the product?
>>>
>>> Yes, it is compatible. We have upgraded Swagger UI to 3.x version, which
>>> is having support for both Swagger 2.0 and Open API 3.0. Basically, the
>>> current swagger ui embedded in APIM supports both versions, but we need to
>>> carefully handle the custom elements that we inject to swagger definition
>>> before rendering it to API Store ie: gateway environment details, security
>>> definitions etc (There are differences of specifying API endpoints and
>>> security definitions Swagger 2.0 and Open API 3.0)
>>>
>>>
>>> @Roshan
>>>
>>>
>>> Do we have a significant difference between swagger and openAPI?
>>> According to the https://swagger.io/blog/difference-between-swagger-and-
>>> openapi/, swagger is a tool and openAPI is the spec it self.
>>>
>>> Yes, there are some significant differences between Swagger 2.0 and Open
>>> API 3.0 spec. Please refer to [1] to have an overview understanding on
>>> whats net in Open API 3.0. Basically swagger spec has been renamed as
>>> OpenAPI as it was donated to Linux foundation and technically OpenAPI 3.0
>>> is the Swagger spec version 3.0. But still, openAPI uses the swagger tools
>>> ie: Swagger UI, Swagger Editor, Swagger codegen
>>>
>>> Do we need to concern about swagger definition vs openAPI definition,
>>> rather versions of it?
>>> Since OpenAPI 3.0 has to be considered as the Swagger 3.0, we need to
>>> consider the version.
>>>
>>> [1] https://blog.readme.io/an-example-filled-guide-to-swagger-3-2/
>>>
>>> On Wed, Jan 10, 2018 at 4:55 AM, roshan wijesena 
>>> wrote:
>>>
 Folks,

 Do we have a significant difference between swagger and openAPI?
 According to the https://swagger.io/blog/di
 fference-between-swagger-and-openapi/, swagger is a tool and openAPI
 is the spec it self.

 Do we need to concern about swagger definition vs openAPI definition,
 rather versions of it?

 Regards
 Roshan



 On Wed, Jan 10, 2018 at 7:25 AM, Harsha Kumara 
 wrote:

>
>
> On Tue, Jan 9, 2018 at 10:57 AM, Thilini Shanika 
> wrote:
>
>> @Bhathiya,
>>
>> Our initial plan was to provide an advanced option for developers to
>> decide the version(Whether in Swagger 2.0 or OpenAPI 3.0)  of the
>> generating swagger definition, but later we decided to stick to OpenAPI 
>> 3.0
>> for newly creating APIs to avoid some complexities in supporting both
>> versions for APIs which are created from scratch in API Publisher. We 
>> would
>> further check the feasibility and alternative solutions of supporting 
>> both
>> versions in API Design phase.
>>
>> @Chamila
>> Thanks for bringing this up for discussion. Yes, we are planning to
>> support both swagger versions in REST APIs like API create, API update, 
>> API
>> Definition Update etc.
>>
> In this case will our swagger console in store compatible with
> multiple swagger versions? How would be the compatibility of swagger
> library across multiple versions that we currently used in the product?
>
>>
>> @Lakmal
>> I moved the summery of the conversation to [1] and we can continue
>> the rest of the discussion in the GitHub issue itself.
>>
>> On Tue, Jan 9, 2018 at 9:37 AM, Lakmal Warusawithana > > wrote:
>>
>>> Hi Thilini,
>>>
>>> Shall we add this discussion into issue [1] itself.  It will be easy
>>> to external party to get involve.
>>>
>>> On Mon, Jan 8, 2018 at 2:28 PM, Thilini Shanika 
>>> wrote:
>>>
 Hi All,

 We are planning to 

Re: [Architecture] OIDC request object support

[Johann Nallathamby]

Hi Hasanthi,

On Wed, Jan 24, 2018 at 11:14 PM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> 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 <
>> hasan...@wso2.com> 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.

>
>
>> "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 
> wrote:
>
>>
>>
>> On Wed, Jan 24, 2018 at 2:12 PM, Farasath Ahamed 
>> wrote:
>>
>>>
>>>
>>> On Tuesday, January 23, 2018, Johann Nallathamby 
>>> wrote:
>>>
 Hi Farasath,

 On Tue, Jan 23, 2018 at 12:13 PM, Farasath Ahamed 
 wrote:

>
>
> On Tuesday, January 23, 2018, Johann Nallathamby 
> wrote:
>
>> Hi Hasanthi,
>>
>> On Tue, Jan 23, 2018 at 9:31 AM, 

Re: [Architecture] OpenAPI 3.0 support for API Manager 2.2.0

[Nuwan Dias]

If someone creates an API from the UI, the default swagger doc will be in
version 3 right? Can a developer switch back to a 2.0 based definition if
so?

On Thu, 25 Jan 2018 at 9:45 am, Thilini Shanika  wrote:

> Hi All,
>
> We have been supporting client side SDK generation via API Store and API
> Store REST APIs, for swagger 2.0 based definitions. But currently, we are
> unable to support this particular feature fo OAS 3 based APIs, since the
> swagger codegen 3.x version, which is having OAS 3.0.0 support, is not
> released yet.
>
> Thus, shall we disable this functionality for OAS 3 specific APIs?
> Basically, we should disable the SDK generation via API Store and REST
> APIs, if it is an OAS 3.0.0 based API.
>
> WDYT?
>
>
> On Wed, Jan 10, 2018 at 10:54 AM, Thilini Shanika 
> wrote:
>
>> @Harsha
>>
>> In this case will our swagger console in store compatible with multiple
>> swagger versions? How would be the compatibility of swagger library across
>> multiple versions that we currently used in the product?
>>
>> Yes, it is compatible. We have upgraded Swagger UI to 3.x version, which
>> is having support for both Swagger 2.0 and Open API 3.0. Basically, the
>> current swagger ui embedded in APIM supports both versions, but we need to
>> carefully handle the custom elements that we inject to swagger definition
>> before rendering it to API Store ie: gateway environment details, security
>> definitions etc (There are differences of specifying API endpoints and
>> security definitions Swagger 2.0 and Open API 3.0)
>>
>>
>> @Roshan
>>
>>
>> Do we have a significant difference between swagger and openAPI?
>> According to the
>> https://swagger.io/blog/difference-between-swagger-and-openapi/, swagger
>> is a tool and openAPI is the spec it self.
>>
>> Yes, there are some significant differences between Swagger 2.0 and Open
>> API 3.0 spec. Please refer to [1] to have an overview understanding on
>> whats net in Open API 3.0. Basically swagger spec has been renamed as
>> OpenAPI as it was donated to Linux foundation and technically OpenAPI 3.0
>> is the Swagger spec version 3.0. But still, openAPI uses the swagger tools
>> ie: Swagger UI, Swagger Editor, Swagger codegen
>>
>> Do we need to concern about swagger definition vs openAPI definition,
>> rather versions of it?
>> Since OpenAPI 3.0 has to be considered as the Swagger 3.0, we need to
>> consider the version.
>>
>> [1] https://blog.readme.io/an-example-filled-guide-to-swagger-3-2/
>>
>> On Wed, Jan 10, 2018 at 4:55 AM, roshan wijesena 
>> wrote:
>>
>>> Folks,
>>>
>>> Do we have a significant difference between swagger and openAPI?
>>> According to the
>>> https://swagger.io/blog/difference-between-swagger-and-openapi/,
>>> swagger is a tool and openAPI is the spec it self.
>>>
>>> Do we need to concern about swagger definition vs openAPI definition,
>>> rather versions of it?
>>>
>>> Regards
>>> Roshan
>>>
>>>
>>>
>>> On Wed, Jan 10, 2018 at 7:25 AM, Harsha Kumara  wrote:
>>>


 On Tue, Jan 9, 2018 at 10:57 AM, Thilini Shanika 
 wrote:

> @Bhathiya,
>
> Our initial plan was to provide an advanced option for developers to
> decide the version(Whether in Swagger 2.0 or OpenAPI 3.0)  of the
> generating swagger definition, but later we decided to stick to OpenAPI 
> 3.0
> for newly creating APIs to avoid some complexities in supporting both
> versions for APIs which are created from scratch in API Publisher. We 
> would
> further check the feasibility and alternative solutions of supporting both
> versions in API Design phase.
>
> @Chamila
> Thanks for bringing this up for discussion. Yes, we are planning to
> support both swagger versions in REST APIs like API create, API update, 
> API
> Definition Update etc.
>
 In this case will our swagger console in store compatible with multiple
 swagger versions? How would be the compatibility of swagger library across
 multiple versions that we currently used in the product?

>
> @Lakmal
> I moved the summery of the conversation to [1] and we can continue the
> rest of the discussion in the GitHub issue itself.
>
> On Tue, Jan 9, 2018 at 9:37 AM, Lakmal Warusawithana 
> wrote:
>
>> Hi Thilini,
>>
>> Shall we add this discussion into issue [1] itself.  It will be easy
>> to external party to get involve.
>>
>> On Mon, Jan 8, 2018 at 2:28 PM, Thilini Shanika 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are planning to provide OpenAPI 3.0 specification support for API
>>> Manager 2.2.0 [1]. We did a background research on what's new in OpenAPI
>>> and the feasibility of providing OpenAPI 3.0 support over APIM 2.2.0. As
>>> per the current architecture of APIM, it is feasible to support OpenAPI 

Re: [Architecture] OpenAPI 3.0 support for API Manager 2.2.0

[Thilini Shanika]

Hi All,

We have been supporting client side SDK generation via API Store and API
Store REST APIs, for swagger 2.0 based definitions. But currently, we are
unable to support this particular feature fo OAS 3 based APIs, since the
swagger codegen 3.x version, which is having OAS 3.0.0 support, is not
released yet.

Thus, shall we disable this functionality for OAS 3 specific APIs?
Basically, we should disable the SDK generation via API Store and REST
APIs, if it is an OAS 3.0.0 based API.

WDYT?


On Wed, Jan 10, 2018 at 10:54 AM, Thilini Shanika  wrote:

> @Harsha
>
> In this case will our swagger console in store compatible with multiple
> swagger versions? How would be the compatibility of swagger library across
> multiple versions that we currently used in the product?
>
> Yes, it is compatible. We have upgraded Swagger UI to 3.x version, which
> is having support for both Swagger 2.0 and Open API 3.0. Basically, the
> current swagger ui embedded in APIM supports both versions, but we need to
> carefully handle the custom elements that we inject to swagger definition
> before rendering it to API Store ie: gateway environment details, security
> definitions etc (There are differences of specifying API endpoints and
> security definitions Swagger 2.0 and Open API 3.0)
>
>
> @Roshan
>
>
> Do we have a significant difference between swagger and openAPI? According
> to the https://swagger.io/blog/difference-between-swagger-and-openapi/,
> swagger is a tool and openAPI is the spec it self.
>
> Yes, there are some significant differences between Swagger 2.0 and Open
> API 3.0 spec. Please refer to [1] to have an overview understanding on
> whats net in Open API 3.0. Basically swagger spec has been renamed as
> OpenAPI as it was donated to Linux foundation and technically OpenAPI 3.0
> is the Swagger spec version 3.0. But still, openAPI uses the swagger tools
> ie: Swagger UI, Swagger Editor, Swagger codegen
>
> Do we need to concern about swagger definition vs openAPI definition,
> rather versions of it?
> Since OpenAPI 3.0 has to be considered as the Swagger 3.0, we need to
> consider the version.
>
> [1] https://blog.readme.io/an-example-filled-guide-to-swagger-3-2/
>
> On Wed, Jan 10, 2018 at 4:55 AM, roshan wijesena 
> wrote:
>
>> Folks,
>>
>> Do we have a significant difference between swagger and openAPI?
>> According to the https://swagger.io/blog/difference-between-swagger-and-o
>> penapi/, swagger is a tool and openAPI is the spec it self.
>>
>> Do we need to concern about swagger definition vs openAPI definition,
>> rather versions of it?
>>
>> Regards
>> Roshan
>>
>>
>>
>> On Wed, Jan 10, 2018 at 7:25 AM, Harsha Kumara  wrote:
>>
>>>
>>>
>>> On Tue, Jan 9, 2018 at 10:57 AM, Thilini Shanika 
>>> wrote:
>>>
 @Bhathiya,

 Our initial plan was to provide an advanced option for developers to
 decide the version(Whether in Swagger 2.0 or OpenAPI 3.0)  of the
 generating swagger definition, but later we decided to stick to OpenAPI 3.0
 for newly creating APIs to avoid some complexities in supporting both
 versions for APIs which are created from scratch in API Publisher. We would
 further check the feasibility and alternative solutions of supporting both
 versions in API Design phase.

 @Chamila
 Thanks for bringing this up for discussion. Yes, we are planning to
 support both swagger versions in REST APIs like API create, API update, API
 Definition Update etc.

>>> In this case will our swagger console in store compatible with multiple
>>> swagger versions? How would be the compatibility of swagger library across
>>> multiple versions that we currently used in the product?
>>>

 @Lakmal
 I moved the summery of the conversation to [1] and we can continue the
 rest of the discussion in the GitHub issue itself.

 On Tue, Jan 9, 2018 at 9:37 AM, Lakmal Warusawithana 
 wrote:

> Hi Thilini,
>
> Shall we add this discussion into issue [1] itself.  It will be easy
> to external party to get involve.
>
> On Mon, Jan 8, 2018 at 2:28 PM, Thilini Shanika 
> wrote:
>
>> Hi All,
>>
>> We are planning to provide OpenAPI 3.0 specification support for API
>> Manager 2.2.0 [1]. We did a background research on what's new in OpenAPI
>> and the feasibility of providing OpenAPI 3.0 support over APIM 2.2.0. As
>> per the current architecture of APIM, it is feasible to support OpenAPI 
>> 3.0
>> spec, parallel with Swagger 2.0 (Swagger 2.0 support is required for
>> migrated APIs from previous releases)
>>
>> Following are the functionalities we are planning to ship with this
>> new feature.
>>
>>1. Supporting OpenAPI 3.0 spec for newly designing/Creating APIs
>>(When an API is created from the scratch, the underneath API 

Re: [Architecture] [RRT] Calculate Age value of cached response

[Dimuthu Leelarathne]

Hi Harsha,

This is part of the specification. You can see the "Age header"

https://tools.ietf.org/html/rfc2616#page-124

thanks,
Dimuthu


On Wed, Jan 24, 2018 at 9:19 PM, Harsha Kumara  wrote:

>
>
> On Wed, Jan 24, 2018 at 3:34 PM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> Hi All,
>>
>> I need to get the cached response fetched time from origin server which
>> is returned in the BE response with Date header. When I debugged the
>> cache-mediator code, I found that when caching the response Date header is
>> added to the cache. But when I retrieve the cached response for the
>> subsequent request, Date header is removed from the cached response.
>>
>> This is due to we are removing the Date header from the response [1] and
>> send a new Date header with the response to the user. If we set the
>> preserveHeaders(in passthru-http.properties), I was able to get the Date
>> header from the cached response as well.
>>
>> So, as I need the response fetched time to calculate the TTL value of the
>> cached response, I am planning to add a property to the cached response to
>> store the fetched time and use it to calculate the TTL. Or do we need to
>> suggest the user to set the preserve header?
>>
> I think adding a property is better rather adding header to the response.
>
>>
>>
>> [1]. https://github.com/wso2/wso2-synapse/blob/master/module
>> s/transports/core/nhttp/src/main/java/org/apache/synapse/
>> transport/passthru/util/PassThroughTransportUtils.java#L160
>>
>> Thanks,
>> Keerthika.
>>
>> On Tue, Jan 23, 2018 at 8:26 PM, Keerthika Mahendralingam <
>> keerth...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> I am trying to add an Age header when returning the cached response(as
>>> discussed in [1]). I am following the steps as follows:
>>>
>>>- If the response doesn't have the Date header, add Date header
>>>(with current time) when caching the response[2].
>>>- For the subsequent request, get the Date header value of the
>>>cached response, timeout and current requested time and find the TTL 
>>> value
>>>as:
>>>
>>> TTL = difference ((DateHeaderValue + timeout), CurrentTime)
>>>
>>>
>>>- Set the TTL value as Age header.
>>>
>>> Please let me know if you have any concerns on this.
>>>
>>> [1]. [Architecture][RRT] Improving caching based on cache-control and
>>> ETag headers
>>> [2]. https://tools.ietf.org/html/rfc2616#page-124
>>>
>>> Thanks,
>>> Keerthika.
>>> --
>>> 
>>> Keerthika Mahendralingam
>>> Software Engineer
>>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144>
>>> keerth...@wso2.com
>>> WSO2, Inc.
>>> lean . enterprise . middleware
>>>
>>
>>
>>
>> --
>> 
>> Keerthika Mahendralingam
>> Software Engineer
>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144>
>> keerth...@wso2.com
>> WSO2, Inc.
>> lean . enterprise . middleware
>>
>
>
>
> --
> Harsha Kumara
> Software Engineer, WSO2 Inc.
> Mobile: +94775505618 <077%20550%205618>
> Blog:harshcreationz.blogspot.com
>



-- 
Dimuthu Leelarathne
Director, Solutions Architecture

WSO2, Inc. (http://wso2.com)
email: dimut...@wso2.com
Mobile: +94773661935
Blog: http://muthulee.blogspot.com

Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [MB4] Exposing messaging metrics

[Asitha Nanayakkara]

Hi Gihan,

We might be able to expose the metrics over HTTP using their build in
http-reporter. See reporting via HTTP in [1]
Currently, we are using metrics version 2.3.7 coming from the
carbon-metrics component. Not sure whether this feature is supported in
that version.

[1] http://metrics.dropwizard.io/3.1.0/getting-started/

Regards,
Asitha


On Wed, Jan 24, 2018 at 6:42 PM, Gihan Anuruddha  wrote:

> Hi Asanka,
>
> Do you have a plan to expose above information through REST API?
>
> Regards,
> Gihan
>
> On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera 
> wrote:
>
>> Hi all,
>>
>> We need to expose messaging metrics to provide information about the
>> broker state. We are planning to expose following messaging metrics.
>>
>>- Queue
>>   - Number of messages
>>   - Number of messages in a specific queue*
>>   - Number of subscribers for a specific queue*
>>   - Total messages published (enqueued)
>>   - Number of messages published to a queue*
>>   - Total messages acknowledged (dequeued)
>>   - Number of messages acknowledged in a queue*
>>- Exchanges
>>   - Total messages published
>>   - Number of messages published with a certain routing key*
>>- Subscriptions
>>   - Total subscribers
>>   - Number of pending messages*
>>   - Total messages fetched*
>>   - Total messages acknowledged*
>>   - Total messages rejected*
>>- Database
>>   - Read latency
>>   - Write latency
>>   - Delete latency
>>   - Read throughput
>>   - Write throughput
>>   - Delete throughput
>>- Broker
>>   - Messages in inbound netty pipeline
>>   - Messages in data cache layer
>>
>> * - We will have to evaluate calculating dynamic metrics since it can
>> depend on the library support and performance impact on the broker.
>>
>> Please suggest other messaging metrics we need to expose.
>>
>> The metric calculation should not have a considerable negative impact on
>> the broker performance. We are planning to use the Metrics library [1]
>> since it is known to have a low footprint on the performance.
>>
>> WDYT?
>> [1]. http://isuru-perera.blogspot.com/2014/11/java-performance-mo
>> nitoring-libraries.html
>> [2]. https://github.com/dropwizard/metrics
>>
>> --
>> Asanka Abeyweera
>> Associate Technical Lead
>> WSO2 Inc.
>>
>> Phone: +94 712228648 <071%20222%208648>
>> Blog: a5anka.github.io
>>
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> W.G. Gihan Anuruddha
> Associate Technical Lead | WSO2, Inc.
> M: +94772272595
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Asitha Nanayakkara* 
Associate Technical Lead
WSO2, Inc. 
Mob: +94 77 853 0682 <+94%2077%20853%200682>
[image: https://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OIDC request object support

[Hasanthi Purnima Dissanayake]

Hi Johann,

First of all apologies for the late reply :).

Hi Hasanthi,
>
> On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> 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.


> "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? 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?

Thanks,




On Wed, Jan 24, 2018 at 9:14 PM, Johann Nallathamby  wrote:

>
>
> On Wed, Jan 24, 2018 at 2:12 PM, Farasath Ahamed 
> wrote:
>
>>
>>
>> On Tuesday, January 23, 2018, Johann Nallathamby  wrote:
>>
>>> Hi Farasath,
>>>
>>> On Tue, Jan 23, 2018 at 12:13 PM, Farasath Ahamed 
>>> wrote:
>>>


 On Tuesday, January 23, 2018, Johann Nallathamby 
 wrote:

> Hi Hasanthi,
>
> On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> 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 

Re: [Architecture] [RRT] Calculate Age value of cached response

[Harsha Kumara]

On Wed, Jan 24, 2018 at 3:34 PM, Keerthika Mahendralingam <
keerth...@wso2.com> wrote:

> Hi All,
>
> I need to get the cached response fetched time from origin server which is
> returned in the BE response with Date header. When I debugged the
> cache-mediator code, I found that when caching the response Date header is
> added to the cache. But when I retrieve the cached response for the
> subsequent request, Date header is removed from the cached response.
>
> This is due to we are removing the Date header from the response [1] and
> send a new Date header with the response to the user. If we set the
> preserveHeaders(in passthru-http.properties), I was able to get the Date
> header from the cached response as well.
>
> So, as I need the response fetched time to calculate the TTL value of the
> cached response, I am planning to add a property to the cached response to
> store the fetched time and use it to calculate the TTL. Or do we need to
> suggest the user to set the preserve header?
>
I think adding a property is better rather adding header to the response.

>
>
> [1]. https://github.com/wso2/wso2-synapse/blob/master/
> modules/transports/core/nhttp/src/main/java/org/apache/
> synapse/transport/passthru/util/PassThroughTransportUtils.java#L160
>
> Thanks,
> Keerthika.
>
> On Tue, Jan 23, 2018 at 8:26 PM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> Hi All,
>>
>> I am trying to add an Age header when returning the cached response(as
>> discussed in [1]). I am following the steps as follows:
>>
>>- If the response doesn't have the Date header, add Date header (with
>>current time) when caching the response[2].
>>- For the subsequent request, get the Date header value of the cached
>>response, timeout and current requested time and find the TTL value as:
>>
>> TTL = difference ((DateHeaderValue + timeout), CurrentTime)
>>
>>
>>- Set the TTL value as Age header.
>>
>> Please let me know if you have any concerns on this.
>>
>> [1]. [Architecture][RRT] Improving caching based on cache-control and
>> ETag headers
>> [2]. https://tools.ietf.org/html/rfc2616#page-124
>>
>> Thanks,
>> Keerthika.
>> --
>> 
>> Keerthika Mahendralingam
>> Software Engineer
>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144>
>> keerth...@wso2.com
>> WSO2, Inc.
>> lean . enterprise . middleware
>>
>
>
>
> --
> 
> Keerthika Mahendralingam
> Software Engineer
> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144>
> keerth...@wso2.com
> WSO2, Inc.
> lean . enterprise . middleware
>



-- 
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OIDC request object support

[Johann Nallathamby]

On Wed, Jan 24, 2018 at 2:12 PM, Farasath Ahamed  wrote:

>
>
> On Tuesday, January 23, 2018, Johann Nallathamby  wrote:
>
>> Hi Farasath,
>>
>> On Tue, Jan 23, 2018 at 12:13 PM, Farasath Ahamed 
>> wrote:
>>
>>>
>>>
>>> On Tuesday, January 23, 2018, Johann Nallathamby 
>>> wrote:
>>>
 Hi Hasanthi,

 On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake <
 hasan...@wso2.com> 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 

Re: [Architecture] OIDC request object support

[Johann Nallathamby]

Hi Hasanthi,

On Tue, Jan 23, 2018 at 10:59 AM, Johann Nallathamby 
wrote:

> Hi Hasanthi,
>
> On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> 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?
>

Any idea why we are checking scopes here?

Regards,
Johann.


>
> 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?
>
> Regards,
> Johann.
>
>
>> Thanks,
>>
>>
>> On Tue, Jan 23, 2018 at 9:05 AM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Hasanthi,
>>>
>>> On Wed, Oct 11, 2017 at 4:35 PM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> 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
 _id=X
 _uri=http://localhost:8080/playground
 =openid
 =af0ifjsldkj
 =n-0S6_WzA2Mj
 ={
   "iss": "s6BhdRkqt3",
   "aud": "https://server.example.com;,
   "response_type": "code id_token",
   "client_id": "s6BhdRkqt3",

Re: [Architecture] [APIM][C5] Multi-Environment API Overview Feature

[Chamin Dias]

On Wed, Jan 24, 2018 at 6:12 PM, Sanjeewa Malalgoda 
wrote:

> If one environment trust the user then cant we assume other environment
> which trust initial environment can also accept this as valid user.
>
This is a valid point IMHO. Haven't we evaluated the possibility of this?

> We can even use certificate based grant type of implementation. Then use
> login to one environment successfully that environment should be able to
> obtain token from other environments using certificate based grant by
> passing user name. So next environment should trust and issue token.
>
> Thanks,
> sanjeewa.
>
> On Wed, Jan 24, 2018 at 2:55 PM, Renuka Fernando  wrote:
>
>> Hi all,
>>
>> We are going to authenticate the user to other environments via JWT grant
>> type [1].
>> The feature is disabled by default and the below configuration is going
>> to be used to enable the feature. If JWT grant type is not supported by the
>> IDP, the user can use a similar grant as an extension point.
>>
>>   # APIM Configuration Parameterswso2.carbon.apimgt:
>> # Environment Configurations
>>   environmentConfigurations:
>>   # Multi-Environment Overview Configurations
>> environmentOverviewConfigs:
>> # Multi-Environment Overview feature enabled or not
>>   enabled: false
>> # Authentication Grant Type to authenticate user to other 
>> environments
>>   authenticationGrantType: "urn:ietf:params:oauth:grant-type:jwt-bearer"
>>
>>
>> Appreciate any suggestions.
>> Thanks
>>
>> [1] see the mail on subject "[APIM 3.0.0] Authenticate a user to all
>> environments when login to one environment"
>> [2] https://github.com/wso2/product-apim/issues/2299
>>
>>
>> Best regards
>> Renuka
>>
>> On 9 January 2018 at 16:19, Renuka Fernando  wrote:
>>
>>> Hi All,
>>>
>>> We are planning to implement a feature that enables the users to get the
>>> Multi-Environment API Overview of APIs that they are managing across multi
>>> environments. Please refer the GitHub issue[1]. Appreciate any
>>> suggestions and comment on the Github issue about your suggestions.
>>>
>>> [1] https://github.com/wso2/product-apim/issues/2299
>>>
>>> Appreciate any suggestions.
>>> Thanks
>>>
>>> Best regards
>>>
>>> --
>>> *Renuka Fernando*
>>> Software Engineering Intern | WSO2 Inc
>>>
>>> Email : ren...@wso2.com
>>> Mobile : +94 76 667 8752 <+94%2076%20667%208752>
>>> Web : http://wso2.com
>>> 
>>>
>>
>>
>>
>> --
>> *Renuka Fernando*
>> Software Engineering Intern | WSO2 Inc
>>
>> Email : ren...@wso2.com
>> Mobile : +94 76 667 8752 <076%20667%208752>
>> Web : http://wso2.com
>> 
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Chamin Dias
Mobile : 0716097455
Email : cham...@wso2.com
LinkedIn : https://www.linkedin.com/in/chamindias
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [MB4] Exposing messaging metrics

[Gihan Anuruddha]

Hi Asanka,

Do you have a plan to expose above information through REST API?

Regards,
Gihan

On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera 
wrote:

> Hi all,
>
> We need to expose messaging metrics to provide information about the
> broker state. We are planning to expose following messaging metrics.
>
>- Queue
>   - Number of messages
>   - Number of messages in a specific queue*
>   - Number of subscribers for a specific queue*
>   - Total messages published (enqueued)
>   - Number of messages published to a queue*
>   - Total messages acknowledged (dequeued)
>   - Number of messages acknowledged in a queue*
>- Exchanges
>   - Total messages published
>   - Number of messages published with a certain routing key*
>- Subscriptions
>   - Total subscribers
>   - Number of pending messages*
>   - Total messages fetched*
>   - Total messages acknowledged*
>   - Total messages rejected*
>- Database
>   - Read latency
>   - Write latency
>   - Delete latency
>   - Read throughput
>   - Write throughput
>   - Delete throughput
>- Broker
>   - Messages in inbound netty pipeline
>   - Messages in data cache layer
>
> * - We will have to evaluate calculating dynamic metrics since it can
> depend on the library support and performance impact on the broker.
>
> Please suggest other messaging metrics we need to expose.
>
> The metric calculation should not have a considerable negative impact on
> the broker performance. We are planning to use the Metrics library [1]
> since it is known to have a low footprint on the performance.
>
> WDYT?
> [1]. http://isuru-perera.blogspot.com/2014/11/java-performance-
> monitoring-libraries.html
> [2]. https://github.com/dropwizard/metrics
>
> --
> Asanka Abeyweera
> Associate Technical Lead
> WSO2 Inc.
>
> Phone: +94 712228648 <071%20222%208648>
> Blog: a5anka.github.io
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
W.G. Gihan Anuruddha
Associate Technical Lead | WSO2, Inc.
M: +94772272595
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [DAS][Feature] Display the Spark script execution time in the admin console

[Gihan Anuruddha]

Hi Nirmal,

We already have couples of MBean[1] that exposed last execution start time
for the given script. But definitely a useful feature if we can display
this through the UI in a user friendly manner.

[1] -
https://github.com/wso2/carbon-analytics/tree/release-1.2.3/components/analytics-processors/org.wso2.carbon.analytics.spark.core/src/main/java/org/wso2/carbon/analytics/spark/core/internal/jmx

Regards,
Gihan

On Tue, Jan 23, 2018 at 10:45 AM, Rukshan Premathunga 
wrote:

> Sorry, I have a typo. What I meant to tell is "last execution duration"
>> (how long it took to run a spark script last time). Averages are important
>> to observe any latency introduced, with time.
>
> +1. Sometimes script take longer time to execute the script due to
> hardware limitation. So it is hard to guess what was wrong and unable to
> check the time taken to execute.
>
> Also in spark job monitoring page(http://localhost:4041/jobs/) also we
> can extract some related information right? But their it is really hard to
> get information based on the script. So your feature is to check time
> duration of the script and is there anyway to check time duration of the
> specific query using monitoring page or something?
>
> Thanks and Regards
>
> On Mon, Jan 22, 2018 at 3:45 PM, Nirmal Fernando  wrote:
>
>> Sorry, I have a typo. What I meant to tell is "last execution duration"
>> (how long it took to run a spark script last time). Averages are important
>> to observe any latency introduced, with time.
>>
>> On Mon, Jan 22, 2018 at 3:37 PM, Damith Wickramasinghe 
>> wrote:
>>
>>> Hi Nirmal,
>>>
>>> +1 for showing last execution time against each spark script which ran
>>> successfully. But why we need the stat of average execution times ? for the
>>> administrators need to know is whether the specific spark script has ran
>>> successfully . By showing the last execution time , he/she can determine
>>> whether it ran as per the specific cron interval.
>>>
>>> Regards,
>>> Damith
>>>
>>> On Mon, Jan 22, 2018 at 3:25 PM, Nirmal Fernando 
>>> wrote:
>>>
 Hi All,

 Currently, there's no way to see the last execution time against
 scheduled spark scripts of DAS. I think it'll be a useful feature for DAS
 administrators. Wdyt?

 Further, if we can calculate the average execution times of a spark
 script during last hour, past day that'll be useful as well. Since it's an
 average calculation, there won't be a big overhead.

 --

 Thanks & regards,
 Nirmal

 Technical Lead, WSO2 Inc.
 Mobile: +94715779733 <+94%2071%20577%209733>
 Blog: http://nirmalfdo.blogspot.com/



>>>
>>>
>>> --
>>> Senior Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> 
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94728671315 <+94%2072%20867%201315>*
>>>
>>>
>>
>>
>> --
>>
>> Thanks & regards,
>> Nirmal
>>
>> Technical Lead, WSO2 Inc.
>> Mobile: +94715779733 <+94%2071%20577%209733>
>> Blog: http://nirmalfdo.blogspot.com/
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
> +94711822074 <071%20182%202074>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
W.G. Gihan Anuruddha
Associate Technical Lead | WSO2, Inc.
M: +94772272595
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] Multi-Environment API Overview Feature

[Sanjeewa Malalgoda]

If one environment trust the user then cant we assume other environment
which trust initial environment can also accept this as valid user.
We can even use certificate based grant type of implementation. Then use
login to one environment successfully that environment should be able to
obtain token from other environments using certificate based grant by
passing user name. So next environment should trust and issue token.

Thanks,
sanjeewa.

On Wed, Jan 24, 2018 at 2:55 PM, Renuka Fernando  wrote:

> Hi all,
>
> We are going to authenticate the user to other environments via JWT grant
> type [1].
> The feature is disabled by default and the below configuration is going to
> be used to enable the feature. If JWT grant type is not supported by the
> IDP, the user can use a similar grant as an extension point.
>
>   # APIM Configuration Parameterswso2.carbon.apimgt:
> # Environment Configurations
>   environmentConfigurations:
>   # Multi-Environment Overview Configurations
> environmentOverviewConfigs:
> # Multi-Environment Overview feature enabled or not
>   enabled: false
> # Authentication Grant Type to authenticate user to other environments
>   authenticationGrantType: "urn:ietf:params:oauth:grant-type:jwt-bearer"
>
>
> Appreciate any suggestions.
> Thanks
>
> [1] see the mail on subject "[APIM 3.0.0] Authenticate a user to all
> environments when login to one environment"
> [2] https://github.com/wso2/product-apim/issues/2299
>
>
> Best regards
> Renuka
>
> On 9 January 2018 at 16:19, Renuka Fernando  wrote:
>
>> Hi All,
>>
>> We are planning to implement a feature that enables the users to get the
>> Multi-Environment API Overview of APIs that they are managing across multi
>> environments. Please refer the GitHub issue[1]. Appreciate any
>> suggestions and comment on the Github issue about your suggestions.
>>
>> [1] https://github.com/wso2/product-apim/issues/2299
>>
>> Appreciate any suggestions.
>> Thanks
>>
>> Best regards
>>
>> --
>> *Renuka Fernando*
>> Software Engineering Intern | WSO2 Inc
>>
>> Email : ren...@wso2.com
>> Mobile : +94 76 667 8752 <+94%2076%20667%208752>
>> Web : http://wso2.com
>> 
>>
>
>
>
> --
> *Renuka Fernando*
> Software Engineering Intern | WSO2 Inc
>
> Email : ren...@wso2.com
> Mobile : +94 76 667 8752 <076%20667%208752>
> Web : http://wso2.com
> 
>



-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

blog
:http://sanjeewamalalgoda.blogspot.com/

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [MB4] HA Support

[Gihan Anuruddha]

Hi All,

Without reloading everything when node becomes active from passive state,
is there any possibility of doing lazy loading specially in permission
area? This will speed up the server readiness to serve live traffic.

Regards,
Gihan

On Tue, Jan 23, 2018 at 6:57 PM, Waruna Jayaweera  wrote:

> Hi Maryam,
>
> We also store the permissions related data in both memory and persistent
> storage but permissions will be retrieved from memory. In that case if new
> permissions added to active node, passive node will have inconsistency with
> permissions.
> I hope we can use same above approach for permissions as well.
>
> Thanks,
> Waruna
>
>
>
>
>
> On Fri, Jan 19, 2018 at 6:01 PM, Maryam Ziyad  wrote:
>
>> Hi Asanka,
>>
>> The required queue/binding/exchange related data will be loaded once the
>> previously passive node is notified of becoming the active node.
>>
>> This is considering the possibility of inconsistencies in a continuous
>> sync, which could also require reloading on becoming the active node.
>>
>> Thank you,
>> Maryam
>>
>> On Mon, Jan 15, 2018 at 8:14 AM, Asanka Abeyweera 
>> wrote:
>>
>>> Hi Maryam,
>>>
>>> Are we keeping the passive node in sync with the active node or are we
>>> reloading context and message data when a passive node becomes active?
>>>
>>> On Fri, Jan 12, 2018 at 6:46 PM, Maryam Ziyad  wrote:
>>>
 Hi All,

 As mentioned, an extensible point "org.wso2.broker.coordination.HaStrategy"
 has been introduced, which can be implemented to provide variations upon
 which HA support will be based.

 Any new/custom implementation would have to notify the listeners
 listening on node state changes (when a node state changes from active to
 passive or passive to active).

 Currently the modules listening on state changes are as follows:

- broker-core
- broker-transport
- broker-rest-runner

 All nodes will start up in "passive" mode, and only change state to
 "active" on notification by the HA strategy. This requires that the
 listeners are registered prior to starting the HA strategy (identification
 of the active node).


 *Default RDBMS Coordinator Election based HA Strategy *

 With the default HA strategy (RdbmsHaStrategy - implemented based on
 the RDBMS based coordinator election approach [1]), the possible
 coordination node states are mapped to active/passive as follows:

- COORDINATOR - Active
- CANDIDATE - Passive
- ELECTION - Passive

 Thus notification of the HA listeners happens when:

- election is triggered and the node was previously the coordinator
node (active → passive)
- election resulted in the node becoming the coordinator node
(passive → active)

 [1] https://github.com/wso2/message-broker/pull/74

 Feedback/suggestions would be highly appreciated.

 Thank you,
 Maryam

 On Fri, Jan 12, 2018 at 6:41 PM, Maryam Ziyad  wrote:

> Hi Asanka,
>
> Renamed "haConfig" to "failover" based on the offline discussion.
>
> Thank you,
> Maryam
>
> On Tue, Dec 19, 2017 at 7:05 PM, Asanka Abeyweera 
> wrote:
>
>> Hi Maryam,
>>
>> Shall we rename the "haConfig" to "ha-clustering"? I'm not sure if we
>> should use camel case in the yaml config.
>>
>> On Tue, Dec 19, 2017 at 4:42 PM, Maryam Ziyad 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are currently working on introducing $subject [1]. Please find
>>> below a high level description of the approach.
>>>
>>> An extension point (HaStrategy) will be introduced, allowing
>>> straightforward introduction of different implementations of 
>>> identification
>>> of the active node, where the only requirements would be that these
>>> approaches extend the common class and invoke particular methods when 
>>> the
>>> node state changes.
>>>
>>> The broker-core and broker-transport (broker-amqp) modules would
>>> introduce listeners to receive notifications of node states changes
>>> (active/passive), and change behaviour accordingly.
>>>
>>>
>>> ​
>>>
>>> *Configuration*
>>>
>>> The HA related configuration would be specified in the broker.yaml
>>> file including whether HA is enabled and the HA strategy to use.
>>>
>>> haConfig:
>>>  enabled: true
>>>  strategy: org.wso2.broker.coordination.rdbms.RdbmsHaStrategy
>>>
>>>
>>> The basic/initial HA strategy implementation will be the
>>> RdbmsHaStrategy based on the RDBMS based coordinator election approach
>>> previously introduced for MB 3.2.0. [2, 3]. ​If HA enabled is set to 
>>> true
>>> but no strategy is specified, the 

Re: [Architecture] [RRT] Calculate Age value of cached response

[Keerthika Mahendralingam]

Hi All,

I need to get the cached response fetched time from origin server which is
returned in the BE response with Date header. When I debugged the
cache-mediator code, I found that when caching the response Date header is
added to the cache. But when I retrieve the cached response for the
subsequent request, Date header is removed from the cached response.

This is due to we are removing the Date header from the response [1] and
send a new Date header with the response to the user. If we set the
preserveHeaders(in passthru-http.properties), I was able to get the Date
header from the cached response as well.

So, as I need the response fetched time to calculate the TTL value of the
cached response, I am planning to add a property to the cached response to
store the fetched time and use it to calculate the TTL. Or do we need to
suggest the user to set the preserve header?


[1].
https://github.com/wso2/wso2-synapse/blob/master/modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/passthru/util/PassThroughTransportUtils.java#L160

Thanks,
Keerthika.

On Tue, Jan 23, 2018 at 8:26 PM, Keerthika Mahendralingam <
keerth...@wso2.com> wrote:

> Hi All,
>
> I am trying to add an Age header when returning the cached response(as
> discussed in [1]). I am following the steps as follows:
>
>- If the response doesn't have the Date header, add Date header (with
>current time) when caching the response[2].
>- For the subsequent request, get the Date header value of the cached
>response, timeout and current requested time and find the TTL value as:
>
> TTL = difference ((DateHeaderValue + timeout), CurrentTime)
>
>
>- Set the TTL value as Age header.
>
> Please let me know if you have any concerns on this.
>
> [1]. [Architecture][RRT] Improving caching based on cache-control and ETag
> headers
> [2]. https://tools.ietf.org/html/rfc2616#page-124
>
> Thanks,
> Keerthika.
> --
> 
> Keerthika Mahendralingam
> Software Engineer
> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144>
> keerth...@wso2.com
> WSO2, Inc.
> lean . enterprise . middleware
>



-- 

Keerthika Mahendralingam
Software Engineer
Mobile :+94 (0) 776 121144
keerth...@wso2.com
WSO2, Inc.
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] Multi-Environment API Overview Feature

[Renuka Fernando]

Hi all,

We are going to authenticate the user to other environments via JWT grant
type [1].
The feature is disabled by default and the below configuration is going to
be used to enable the feature. If JWT grant type is not supported by the
IDP, the user can use a similar grant as an extension point.

  # APIM Configuration Parameterswso2.carbon.apimgt:
# Environment Configurations
  environmentConfigurations:
  # Multi-Environment Overview Configurations
environmentOverviewConfigs:
# Multi-Environment Overview feature enabled or not
  enabled: false
# Authentication Grant Type to authenticate user to other environments
  authenticationGrantType: "urn:ietf:params:oauth:grant-type:jwt-bearer"


Appreciate any suggestions.
Thanks

[1] see the mail on subject "[APIM 3.0.0] Authenticate a user to all
environments when login to one environment"
[2] https://github.com/wso2/product-apim/issues/2299


Best regards
Renuka

On 9 January 2018 at 16:19, Renuka Fernando  wrote:

> Hi All,
>
> We are planning to implement a feature that enables the users to get the
> Multi-Environment API Overview of APIs that they are managing across multi
> environments. Please refer the GitHub issue[1]. Appreciate any
> suggestions and comment on the Github issue about your suggestions.
>
> [1] https://github.com/wso2/product-apim/issues/2299
>
> Appreciate any suggestions.
> Thanks
>
> Best regards
>
> --
> *Renuka Fernando*
> Software Engineering Intern | WSO2 Inc
>
> Email : ren...@wso2.com
> Mobile : +94 76 667 8752 <+94%2076%20667%208752>
> Web : http://wso2.com
> 
>



-- 
*Renuka Fernando*
Software Engineering Intern | WSO2 Inc

Email : ren...@wso2.com
Mobile : +94 76 667 8752
Web : http://wso2.com

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Personal information export API

[Maduranga Siriwardena]

If the user is in secondary userstore, fully qualified username contains
"/" character. But seems to be we can't send url encoded "/" characters
(%2F) in path parameters. We are evaluating possible solutions for this. If
this is not an option, we are planing to base 64 encode the username and
then url encode it.

We already has a web application with name api#identity#user [1]. So we are
planing to use the same repository for this code also.

[1]
https://github.com/wso2-extensions/identity-governance/tree/v1.0.38/components/org.wso2.carbon.identity.user.endpoint


Thanks,

On Tue, Jan 23, 2018 at 10:40 AM, Maduranga Siriwardena 
wrote:

>
>
> On Tue, Jan 23, 2018 at 10:35 AM, Omindu Rathnaweera 
> wrote:
>
>>
>> Hi Maduranga,
>>
>> On Tue, Jan 23, 2018 at 10:23 AM, Maduranga Siriwardena <
>> madura...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> Web app name we have come up for this endpoint is api#identity#user#v1.0
>>> and the path for the endpoint is /pi/users/{userId}. So the whole endpoint
>>> would be
>>>
>>>- for super tenant,
>>>
>>> /api/identity/user/v1.0/pi/users/{userId}
>>>
>>>
>>>- for tenant,
>>>
>>> /t/{tenant-domain}/api/identity/user/v1.0/pi/users/{userId}
>>>
>>> Our initial plan was to use the ID used in Pseudonyms for username
>>> feature [1]. But as the ID used by Pseudonyms for username feature is not
>>> available to outside, we cannot use it here. Next option available to us is
>>> the ID used in SCIM. But as it is not mandatory to have SCIM ID in system
>>> (when SCIM is disabled), we cannot use this option also.
>>>
>>> Because of above reasons, we are planing to use base 64 encoded fully
>>> qualified username as the userId in the above request.
>>>
>>
>> Would like to know the rationale behind base64 encoding the username.
>> Also if it has to be b64 encoded for some reason then it should be base64
>> URL encoded I believe.
>>
>
> Yes this should be url encoding.
>
>>
>>
>>>
>>> Do you have any suggestions?
>>>
>>> [1] [Architecture] GDPR - Pseudonyms For Username
>>>
>>> Thanks,
>>>
>>> On Mon, Jan 22, 2018 at 5:52 PM, Hasintha Indrajee 
>>> wrote:
>>>
 In a federated user scenario, we neither have user information nor
 email address of the user in a case if the user is not JIT. Hence we won't
 be able to share consents with user in an offline method. But still for
 federated users we need to maintain consents which we give out to SPs. We
 can process this offline and store somewhere (consent info ready for
 download). The way we share will depend. eg - For the users who have emails
 we can send them through an email (as a download link). If not we can share
 those information through another medium (eg - user profile at a later
 login)

 On Mon, Jan 22, 2018 at 5:40 PM, Ruwan Abeykoon 
 wrote:

> Hi Hasintha,
> We do not need to export anything we do not keep in our databases.
> Could you please explain further if we need to do anything extra for
> Federated case.
>
> Cheers,
> Ruwan
>
> On Mon, Jan 22, 2018 at 5:33 PM, Hasintha Indrajee 
> wrote:
>
>> Just a quick question. How are we going to cater consents for
>> federated user ? Having consent from 3rd party IDP to IS will not be 
>> enough
>> AFAIU. If we are sharing those information through an SP we need to
>> maintain those consents as well. WDYT ?
>>
>> In that case how can federated users download their consents ?
>>
>> On Mon, Jan 22, 2018 at 5:25 PM, Omindu Rathnaweera 
>> wrote:
>>
>>> Hi Maduranga,
>>>
>>> In the consent API we do not have the option to get multiple
>>> receipts, the API only returns a list of receipt IDs for a given search
>>> criteria. If you need to include receipt data of all the consent 
>>> entries,
>>> you will have to iterate through all the consent IDs and fetch the
>>> individual receipts. Keep in mind that this will likely to generate a
>>> payload of a considerable size.
>>>
>>> Regards,
>>> Omindu.
>>>
>>>
>>> On Mon, Jan 22, 2018 at 5:12 PM, Maduranga Siriwardena <
>>> madura...@wso2.com> wrote:
>>>
 Hi all,

 We are creating a REST API to export user information for IS 5.5.0.

 Swagger at [1] is the initial design of the API.

 In the initial phase we are allowing the data to be exported only
 by the owner of the profile.

 At the moment we are planing to export basic user profile
 information and the consents user has given. Response JSON has 2 parts 
 in
 it.

- basic: this part will have the users profile information
(claims) in wso2 dialect
- consents: this part will have an array of consents user has

Re: [Architecture] OIDC request object support

[Farasath Ahamed]

On Tuesday, January 23, 2018, Johann Nallathamby  wrote:

> Hi Farasath,
>
> On Tue, Jan 23, 2018 at 12:13 PM, Farasath Ahamed 
> wrote:
>
>>
>>
>> On Tuesday, January 23, 2018, Johann Nallathamby  wrote:
>>
>>> Hi Hasanthi,
>>>
>>> On Tue, Jan 23, 2018 at 9:31 AM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> 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