Re: [Architecture] Support for encrypted ID tokens in OIDC

[Vihanga Liyanage]

The Encryption Method mentioned here is the symmetric key encryption
algorithm that is used to encrypt the JWT claims set. We used the Nimbus [1]
 library for the
implementation and within that, they have used the name "Encryption Method"
to identify this algorithm. They have a class defined as
com.nimbusds.jose.EncryptionMethod which wraps all supported symmetric key
encryption algorithms.
I took the name from there. I'm not sure what you mean by "cipher chaining
mode". Is this mentioned in the JWE RFC?

[1] - https://connect2id.com/products/nimbus-jose-jwt

On Wed, Mar 7, 2018 at 10:00 PM, Godwin Shrimal  wrote:

> should be corrected as "Chaining Mode".
>
>
> Thanks
> Godwin
>
> On Wed, Mar 7, 2018 at 5:26 PM, Godwin Shrimal  wrote:
>
>> "Encryption Method" is the correct term/word here? AFAIK It's cipher
>> chaining mode. I know it's a technical word, but still, I feel like we have
>> to use correct naming. Something  like "Chaning Mode".
>>
>>
>> Thanks
>> Godwin
>>
>> On Wed, Mar 7, 2018 at 11:26 AM, Vihanga Liyanage 
>> wrote:
>>
>>> Hi all,
>>>
>>> [Update]
>>> I have completed the second phase of the project, providing service
>>> provider level configurations in admin dashboard to configure encryption
>>> algorithm and encryption method. With this update, once you enable
>>> encrypting id tokens for an SP in the admin dashboard, two select boxes
>>> will appear with supported encryption algorithms and supported encryption
>>> methods. These supported algorithms are pulled from the identity.xml file.
>>>
>>>
>>>
>>> Respective git issue and pull requests are as follows.
>>>
>>>- https://github.com/wso2/product-is/issues/2387
>>>- https://github.com/wso2/carbon-identity-framework/pull/1416
>>>- https://github.com/wso2-extensions/identity-inbound-auth-oau
>>>th/pull/832
>>>
>>> I have also updated the docs as well.
>>>
>>> Thanks,
>>> Vihanga.
>>>
>>> On Tue, Feb 20, 2018 at 2:45 PM, Vihanga Liyanage 
>>> wrote:
>>>
 Hi all,

 [Update]
 I was able to complete the initial development of the proposed project,
 encrypted id token support in OIDC flow. Following are the links related to
 the development.

- An issue was created in product-is repository to track the
development.
   - https://github.com/wso2/product-is/issues/2336
- Pull request is made to identity-inbound-auth-oauth repository
with required updates.
- https://github.com/wso2-extensions/identity-inbound-auth-oau
   th/pull/798
- Pull request is made to product-is repository with updated
playground application to test the feature
- https://github.com/wso2/product-is/pull/2313
- Code review was held to review the code written in both PRs.

 All PRs are merged by now.
 Currently, I'm working on integration test to test the newly added
 feature.

 Thanks,
 Vihanga

 On Fri, Feb 9, 2018 at 5:07 PM, Vihanga Liyanage 
 wrote:

> Yes, Farasath. As for the offline discussions with Drashana, I came to
> the same conclusion and exploring the SAML sample app right now.
>
> Although I'm not sure about signing JWE. I couldn't find anything
> specific about that in the RFC. Also, the API in Nimbus only expects the
> claims set and the public key of the client to create and encrypt a JWE.
> Please do let me know if you find something else.
>
> On Fri, Feb 9, 2018 at 4:34 PM, Farasath Ahamed 
> wrote:
>
>>
>>
>> On Friday, February 9, 2018, Vihanga Liyanage 
>> wrote:
>>
>>> [- Engineering, Strategy]
>>> [+ Architecture, Dev]
>>>
>>> Thanks,
>>> Vihanga
>>>
>>> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage 
>>> wrote:
>>>
 Hi Farasath,

 For the above two points IMO it would be better to provide an
> option at Service Provider OAuth/OIDC configuration. This will be 
> similar
> to what we have done for SAML.
>

 That is the initial idea came to me as well. But shouldn't the
 clients have a choice of deciding that as well? May be through a 
 request
 parameter. To use either JWS or JWE, the client have to support them 
 right?

>>>
>> By enabling the option to encrypt id_token in the service provider
>> configs the client is acknowledging that it can support encrypted
>> id_tokens.
>>
>> AFAIK even for JWE we need to first sign and then encrypt. Also I
>> couldn't find any reference on a standard approach to allow clients to
>> switch between JWS and JWE via a request parameter.
>>
>> If we take a look at how we handle this is SAML, we have an 

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Godwin Shrimal]

should be corrected as "Chaining Mode".


Thanks
Godwin

On Wed, Mar 7, 2018 at 5:26 PM, Godwin Shrimal  wrote:

> "Encryption Method" is the correct term/word here? AFAIK It's cipher
> chaining mode. I know it's a technical word, but still, I feel like we have
> to use correct naming. Something  like "Chaning Mode".
>
>
> Thanks
> Godwin
>
> On Wed, Mar 7, 2018 at 11:26 AM, Vihanga Liyanage 
> wrote:
>
>> Hi all,
>>
>> [Update]
>> I have completed the second phase of the project, providing service
>> provider level configurations in admin dashboard to configure encryption
>> algorithm and encryption method. With this update, once you enable
>> encrypting id tokens for an SP in the admin dashboard, two select boxes
>> will appear with supported encryption algorithms and supported encryption
>> methods. These supported algorithms are pulled from the identity.xml file.
>>
>>
>>
>> Respective git issue and pull requests are as follows.
>>
>>- https://github.com/wso2/product-is/issues/2387
>>- https://github.com/wso2/carbon-identity-framework/pull/1416
>>- https://github.com/wso2-extensions/identity-inbound-auth-
>>oauth/pull/832
>>
>> I have also updated the docs as well.
>>
>> Thanks,
>> Vihanga.
>>
>> On Tue, Feb 20, 2018 at 2:45 PM, Vihanga Liyanage 
>> wrote:
>>
>>> Hi all,
>>>
>>> [Update]
>>> I was able to complete the initial development of the proposed project,
>>> encrypted id token support in OIDC flow. Following are the links related to
>>> the development.
>>>
>>>- An issue was created in product-is repository to track the
>>>development.
>>>   - https://github.com/wso2/product-is/issues/2336
>>>- Pull request is made to identity-inbound-auth-oauth repository
>>>with required updates.
>>>- https://github.com/wso2-extensions/identity-inbound-auth-oau
>>>   th/pull/798
>>>- Pull request is made to product-is repository with updated
>>>playground application to test the feature
>>>- https://github.com/wso2/product-is/pull/2313
>>>- Code review was held to review the code written in both PRs.
>>>
>>> All PRs are merged by now.
>>> Currently, I'm working on integration test to test the newly added
>>> feature.
>>>
>>> Thanks,
>>> Vihanga
>>>
>>> On Fri, Feb 9, 2018 at 5:07 PM, Vihanga Liyanage 
>>> wrote:
>>>
 Yes, Farasath. As for the offline discussions with Drashana, I came to
 the same conclusion and exploring the SAML sample app right now.

 Although I'm not sure about signing JWE. I couldn't find anything
 specific about that in the RFC. Also, the API in Nimbus only expects the
 claims set and the public key of the client to create and encrypt a JWE.
 Please do let me know if you find something else.

 On Fri, Feb 9, 2018 at 4:34 PM, Farasath Ahamed 
 wrote:

>
>
> On Friday, February 9, 2018, Vihanga Liyanage 
> wrote:
>
>> [- Engineering, Strategy]
>> [+ Architecture, Dev]
>>
>> Thanks,
>> Vihanga
>>
>> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage 
>> wrote:
>>
>>> Hi Farasath,
>>>
>>> For the above two points IMO it would be better to provide an option
 at Service Provider OAuth/OIDC configuration. This will be similar to 
 what
 we have done for SAML.

>>>
>>> That is the initial idea came to me as well. But shouldn't the
>>> clients have a choice of deciding that as well? May be through a request
>>> parameter. To use either JWS or JWE, the client have to support them 
>>> right?
>>>
>>
> By enabling the option to encrypt id_token in the service provider
> configs the client is acknowledging that it can support encrypted
> id_tokens.
>
> AFAIK even for JWE we need to first sign and then encrypt. Also I
> couldn't find any reference on a standard approach to allow clients to
> switch between JWS and JWE via a request parameter.
>
> If we take a look at how we handle this is SAML, we have an option in
> the SAML configs to say whether the assertion needs to be encrypted or 
> not.
> Once the option to encrypt assertion is enabled SAML assertions will 
> always
> be encrypted for the particular service provider (ie. There is no
> requirement to switch between signed or encrypted assertions)
>
> IMO we can follow the same approach. WDYT?
>
>
 On a separate note, any specific reason why we are discussing this
 in strategy and not in Dev and architecture mailing lists?

 I feel that we need to discuss this feature in architecture mailing
 list to get the input from community.

>>>
>>> No such specific reason at all. On the previous project I did, the
>>> mail was asked to sent to engineering and strategy. 

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Godwin Shrimal]

"Encryption Method" is the correct term/word here? AFAIK It's cipher
chaining mode. I know it's a technical word, but still, I feel like we have
to use correct naming. Something  like "Chaning Mode".


Thanks
Godwin

On Wed, Mar 7, 2018 at 11:26 AM, Vihanga Liyanage  wrote:

> Hi all,
>
> [Update]
> I have completed the second phase of the project, providing service
> provider level configurations in admin dashboard to configure encryption
> algorithm and encryption method. With this update, once you enable
> encrypting id tokens for an SP in the admin dashboard, two select boxes
> will appear with supported encryption algorithms and supported encryption
> methods. These supported algorithms are pulled from the identity.xml file.
>
>
>
> Respective git issue and pull requests are as follows.
>
>- https://github.com/wso2/product-is/issues/2387
>- https://github.com/wso2/carbon-identity-framework/pull/1416
>- https://github.com/wso2-extensions/identity-inbound-
>auth-oauth/pull/832
>
> I have also updated the docs as well.
>
> Thanks,
> Vihanga.
>
> On Tue, Feb 20, 2018 at 2:45 PM, Vihanga Liyanage 
> wrote:
>
>> Hi all,
>>
>> [Update]
>> I was able to complete the initial development of the proposed project,
>> encrypted id token support in OIDC flow. Following are the links related to
>> the development.
>>
>>- An issue was created in product-is repository to track the
>>development.
>>   - https://github.com/wso2/product-is/issues/2336
>>- Pull request is made to identity-inbound-auth-oauth repository with
>>required updates.
>>- https://github.com/wso2-extensions/identity-inbound-auth-oau
>>   th/pull/798
>>- Pull request is made to product-is repository with updated
>>playground application to test the feature
>>- https://github.com/wso2/product-is/pull/2313
>>- Code review was held to review the code written in both PRs.
>>
>> All PRs are merged by now.
>> Currently, I'm working on integration test to test the newly added
>> feature.
>>
>> Thanks,
>> Vihanga
>>
>> On Fri, Feb 9, 2018 at 5:07 PM, Vihanga Liyanage 
>> wrote:
>>
>>> Yes, Farasath. As for the offline discussions with Drashana, I came to
>>> the same conclusion and exploring the SAML sample app right now.
>>>
>>> Although I'm not sure about signing JWE. I couldn't find anything
>>> specific about that in the RFC. Also, the API in Nimbus only expects the
>>> claims set and the public key of the client to create and encrypt a JWE.
>>> Please do let me know if you find something else.
>>>
>>> On Fri, Feb 9, 2018 at 4:34 PM, Farasath Ahamed 
>>> wrote:
>>>


 On Friday, February 9, 2018, Vihanga Liyanage  wrote:

> [- Engineering, Strategy]
> [+ Architecture, Dev]
>
> Thanks,
> Vihanga
>
> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage 
> wrote:
>
>> Hi Farasath,
>>
>> For the above two points IMO it would be better to provide an option
>>> at Service Provider OAuth/OIDC configuration. This will be similar to 
>>> what
>>> we have done for SAML.
>>>
>>
>> That is the initial idea came to me as well. But shouldn't the
>> clients have a choice of deciding that as well? May be through a request
>> parameter. To use either JWS or JWE, the client have to support them 
>> right?
>>
>
 By enabling the option to encrypt id_token in the service provider
 configs the client is acknowledging that it can support encrypted
 id_tokens.

 AFAIK even for JWE we need to first sign and then encrypt. Also I
 couldn't find any reference on a standard approach to allow clients to
 switch between JWS and JWE via a request parameter.

 If we take a look at how we handle this is SAML, we have an option in
 the SAML configs to say whether the assertion needs to be encrypted or not.
 Once the option to encrypt assertion is enabled SAML assertions will always
 be encrypted for the particular service provider (ie. There is no
 requirement to switch between signed or encrypted assertions)

 IMO we can follow the same approach. WDYT?


>>> On a separate note, any specific reason why we are discussing this
>>> in strategy and not in Dev and architecture mailing lists?
>>>
>>> I feel that we need to discuss this feature in architecture mailing
>>> list to get the input from community.
>>>
>>
>> No such specific reason at all. On the previous project I did, the
>> mail was asked to sent to engineering and strategy. So I followed the 
>> same
>> protocol. I'll change that now.
>>
>>>
>>>

 Thanks,
 Vihanga.

 --

 Vihanga Liyanage

 Software Engineer | WS*O₂* Inc.

 M : +*94710124103* | 

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Denuwanthi De Silva]

On Wed, Mar 7, 2018 at 12:56 PM, Vihanga Liyanage  wrote:

> Even with signed id tokens, we didn't persist them in the database. Hense
> I didn't either. Do you see any value in doing so?
>
Then there is no problem.

>
> On Wed, Mar 7, 2018 at 12:46 PM, Denuwanthi De Silva 
> wrote:
>
>>
>>
>> On Wed, Mar 7, 2018 at 11:26 AM, Vihanga Liyanage 
>> wrote:
>>
>>> Hi all,
>>>
>>> [Update]
>>> I have completed the second phase of the project, providing service
>>> provider level configurations in admin dashboard to configure encryption
>>> algorithm and encryption method. With this update, once you enable
>>> encrypting id tokens for an SP in the admin dashboard, two select boxes
>>> will appear with supported encryption algorithms and supported encryption
>>> methods. These supported algorithms are pulled from the identity.xml file.
>>>
>>
>> Do we persist the encrypted ID Token to database at any point? If so, is
>> there any comparison of encrypted ID token with the value in the database?
>> I'm asking this because you seem to be using encryption algorithm with
>> dynamic padding.
>>
>>>
>>>
>>>
>>> Respective git issue and pull requests are as follows.
>>>
>>>- https://github.com/wso2/product-is/issues/2387
>>>- https://github.com/wso2/carbon-identity-framework/pull/1416
>>>- https://github.com/wso2-extensions/identity-inbound-auth-oau
>>>th/pull/832
>>>
>>> I have also updated the docs as well.
>>>
>>> Thanks,
>>> Vihanga.
>>>
>>> On Tue, Feb 20, 2018 at 2:45 PM, Vihanga Liyanage 
>>> wrote:
>>>
 Hi all,

 [Update]
 I was able to complete the initial development of the proposed project,
 encrypted id token support in OIDC flow. Following are the links related to
 the development.

- An issue was created in product-is repository to track the
development.
   - https://github.com/wso2/product-is/issues/2336
- Pull request is made to identity-inbound-auth-oauth repository
with required updates.
- https://github.com/wso2-extensions/identity-inbound-auth-oau
   th/pull/798
- Pull request is made to product-is repository with updated
playground application to test the feature
- https://github.com/wso2/product-is/pull/2313
- Code review was held to review the code written in both PRs.

 All PRs are merged by now.
 Currently, I'm working on integration test to test the newly added
 feature.

 Thanks,
 Vihanga

 On Fri, Feb 9, 2018 at 5:07 PM, Vihanga Liyanage 
 wrote:

> Yes, Farasath. As for the offline discussions with Drashana, I came to
> the same conclusion and exploring the SAML sample app right now.
>
> Although I'm not sure about signing JWE. I couldn't find anything
> specific about that in the RFC. Also, the API in Nimbus only expects the
> claims set and the public key of the client to create and encrypt a JWE.
> Please do let me know if you find something else.
>
> On Fri, Feb 9, 2018 at 4:34 PM, Farasath Ahamed 
> wrote:
>
>>
>>
>> On Friday, February 9, 2018, Vihanga Liyanage 
>> wrote:
>>
>>> [- Engineering, Strategy]
>>> [+ Architecture, Dev]
>>>
>>> Thanks,
>>> Vihanga
>>>
>>> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage 
>>> wrote:
>>>
 Hi Farasath,

 For the above two points IMO it would be better to provide an
> option at Service Provider OAuth/OIDC configuration. This will be 
> similar
> to what we have done for SAML.
>

 That is the initial idea came to me as well. But shouldn't the
 clients have a choice of deciding that as well? May be through a 
 request
 parameter. To use either JWS or JWE, the client have to support them 
 right?

>>>
>> By enabling the option to encrypt id_token in the service provider
>> configs the client is acknowledging that it can support encrypted
>> id_tokens.
>>
>> AFAIK even for JWE we need to first sign and then encrypt. Also I
>> couldn't find any reference on a standard approach to allow clients to
>> switch between JWS and JWE via a request parameter.
>>
>> If we take a look at how we handle this is SAML, we have an option in
>> the SAML configs to say whether the assertion needs to be encrypted or 
>> not.
>> Once the option to encrypt assertion is enabled SAML assertions will 
>> always
>> be encrypted for the particular service provider (ie. There is no
>> requirement to switch between signed or encrypted assertions)
>>
>> IMO we can follow the same approach. WDYT?
>>
>>
> On a separate note, any specific reason why we are discussing 

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Vihanga Liyanage]

Even with signed id tokens, we didn't persist them in the database. Hense I
didn't either. Do you see any value in doing so?

On Wed, Mar 7, 2018 at 12:46 PM, Denuwanthi De Silva 
wrote:

>
>
> On Wed, Mar 7, 2018 at 11:26 AM, Vihanga Liyanage 
> wrote:
>
>> Hi all,
>>
>> [Update]
>> I have completed the second phase of the project, providing service
>> provider level configurations in admin dashboard to configure encryption
>> algorithm and encryption method. With this update, once you enable
>> encrypting id tokens for an SP in the admin dashboard, two select boxes
>> will appear with supported encryption algorithms and supported encryption
>> methods. These supported algorithms are pulled from the identity.xml file.
>>
>
> Do we persist the encrypted ID Token to database at any point? If so, is
> there any comparison of encrypted ID token with the value in the database?
> I'm asking this because you seem to be using encryption algorithm with
> dynamic padding.
>
>>
>>
>>
>> Respective git issue and pull requests are as follows.
>>
>>- https://github.com/wso2/product-is/issues/2387
>>- https://github.com/wso2/carbon-identity-framework/pull/1416
>>- https://github.com/wso2-extensions/identity-inbound-auth-
>>oauth/pull/832
>>
>> I have also updated the docs as well.
>>
>> Thanks,
>> Vihanga.
>>
>> On Tue, Feb 20, 2018 at 2:45 PM, Vihanga Liyanage 
>> wrote:
>>
>>> Hi all,
>>>
>>> [Update]
>>> I was able to complete the initial development of the proposed project,
>>> encrypted id token support in OIDC flow. Following are the links related to
>>> the development.
>>>
>>>- An issue was created in product-is repository to track the
>>>development.
>>>   - https://github.com/wso2/product-is/issues/2336
>>>- Pull request is made to identity-inbound-auth-oauth repository
>>>with required updates.
>>>- https://github.com/wso2-extensions/identity-inbound-auth-oau
>>>   th/pull/798
>>>- Pull request is made to product-is repository with updated
>>>playground application to test the feature
>>>- https://github.com/wso2/product-is/pull/2313
>>>- Code review was held to review the code written in both PRs.
>>>
>>> All PRs are merged by now.
>>> Currently, I'm working on integration test to test the newly added
>>> feature.
>>>
>>> Thanks,
>>> Vihanga
>>>
>>> On Fri, Feb 9, 2018 at 5:07 PM, Vihanga Liyanage 
>>> wrote:
>>>
 Yes, Farasath. As for the offline discussions with Drashana, I came to
 the same conclusion and exploring the SAML sample app right now.

 Although I'm not sure about signing JWE. I couldn't find anything
 specific about that in the RFC. Also, the API in Nimbus only expects the
 claims set and the public key of the client to create and encrypt a JWE.
 Please do let me know if you find something else.

 On Fri, Feb 9, 2018 at 4:34 PM, Farasath Ahamed 
 wrote:

>
>
> On Friday, February 9, 2018, Vihanga Liyanage 
> wrote:
>
>> [- Engineering, Strategy]
>> [+ Architecture, Dev]
>>
>> Thanks,
>> Vihanga
>>
>> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage 
>> wrote:
>>
>>> Hi Farasath,
>>>
>>> For the above two points IMO it would be better to provide an option
 at Service Provider OAuth/OIDC configuration. This will be similar to 
 what
 we have done for SAML.

>>>
>>> That is the initial idea came to me as well. But shouldn't the
>>> clients have a choice of deciding that as well? May be through a request
>>> parameter. To use either JWS or JWE, the client have to support them 
>>> right?
>>>
>>
> By enabling the option to encrypt id_token in the service provider
> configs the client is acknowledging that it can support encrypted
> id_tokens.
>
> AFAIK even for JWE we need to first sign and then encrypt. Also I
> couldn't find any reference on a standard approach to allow clients to
> switch between JWS and JWE via a request parameter.
>
> If we take a look at how we handle this is SAML, we have an option in
> the SAML configs to say whether the assertion needs to be encrypted or 
> not.
> Once the option to encrypt assertion is enabled SAML assertions will 
> always
> be encrypted for the particular service provider (ie. There is no
> requirement to switch between signed or encrypted assertions)
>
> IMO we can follow the same approach. WDYT?
>
>
 On a separate note, any specific reason why we are discussing this
 in strategy and not in Dev and architecture mailing lists?

 I feel that we need to discuss this feature in architecture mailing
 list to get the input from community.

>>>
>>> No such specific reason 

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Vihanga Liyanage]

Hi all,

[Update]
I have completed the second phase of the project, providing service
provider level configurations in admin dashboard to configure encryption
algorithm and encryption method. With this update, once you enable
encrypting id tokens for an SP in the admin dashboard, two select boxes
will appear with supported encryption algorithms and supported encryption
methods. These supported algorithms are pulled from the identity.xml file.



Respective git issue and pull requests are as follows.

   - https://github.com/wso2/product-is/issues/2387
   - https://github.com/wso2/carbon-identity-framework/pull/1416
   - https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/832

I have also updated the docs as well.

Thanks,
Vihanga.

On Tue, Feb 20, 2018 at 2:45 PM, Vihanga Liyanage  wrote:

> Hi all,
>
> [Update]
> I was able to complete the initial development of the proposed project,
> encrypted id token support in OIDC flow. Following are the links related to
> the development.
>
>- An issue was created in product-is repository to track the
>development.
>   - https://github.com/wso2/product-is/issues/2336
>- Pull request is made to identity-inbound-auth-oauth repository with
>required updates.
>- https://github.com/wso2-extensions/identity-inbound-auth-oau
>   th/pull/798
>- Pull request is made to product-is repository with updated
>playground application to test the feature
>- https://github.com/wso2/product-is/pull/2313
>- Code review was held to review the code written in both PRs.
>
> All PRs are merged by now.
> Currently, I'm working on integration test to test the newly added feature.
>
> Thanks,
> Vihanga
>
> On Fri, Feb 9, 2018 at 5:07 PM, Vihanga Liyanage  wrote:
>
>> Yes, Farasath. As for the offline discussions with Drashana, I came to
>> the same conclusion and exploring the SAML sample app right now.
>>
>> Although I'm not sure about signing JWE. I couldn't find anything
>> specific about that in the RFC. Also, the API in Nimbus only expects the
>> claims set and the public key of the client to create and encrypt a JWE.
>> Please do let me know if you find something else.
>>
>> On Fri, Feb 9, 2018 at 4:34 PM, Farasath Ahamed 
>> wrote:
>>
>>>
>>>
>>> On Friday, February 9, 2018, Vihanga Liyanage  wrote:
>>>
 [- Engineering, Strategy]
 [+ Architecture, Dev]

 Thanks,
 Vihanga

 On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage 
 wrote:

> Hi Farasath,
>
> For the above two points IMO it would be better to provide an option
>> at Service Provider OAuth/OIDC configuration. This will be similar to 
>> what
>> we have done for SAML.
>>
>
> That is the initial idea came to me as well. But shouldn't the clients
> have a choice of deciding that as well? May be through a request 
> parameter.
> To use either JWS or JWE, the client have to support them right?
>

>>> By enabling the option to encrypt id_token in the service provider
>>> configs the client is acknowledging that it can support encrypted
>>> id_tokens.
>>>
>>> AFAIK even for JWE we need to first sign and then encrypt. Also I
>>> couldn't find any reference on a standard approach to allow clients to
>>> switch between JWS and JWE via a request parameter.
>>>
>>> If we take a look at how we handle this is SAML, we have an option in
>>> the SAML configs to say whether the assertion needs to be encrypted or not.
>>> Once the option to encrypt assertion is enabled SAML assertions will always
>>> be encrypted for the particular service provider (ie. There is no
>>> requirement to switch between signed or encrypted assertions)
>>>
>>> IMO we can follow the same approach. WDYT?
>>>
>>>
>> On a separate note, any specific reason why we are discussing this in
>> strategy and not in Dev and architecture mailing lists?
>>
>> I feel that we need to discuss this feature in architecture mailing
>> list to get the input from community.
>>
>
> No such specific reason at all. On the previous project I did, the
> mail was asked to sent to engineering and strategy. So I followed the same
> protocol. I'll change that now.
>
>>
>>
>>>
>>> Thanks,
>>> Vihanga.
>>>
>>> --
>>>
>>> Vihanga Liyanage
>>>
>>> Software Engineer | WS*O₂* Inc.
>>>
>>> M : +*94710124103* | http://wso2.com
>>>
>>> [image: http://wso2.com/signature] 
>>>
>>>
>>> 
>>>  Virus-free.
>>> www.avast.com
>>> 
>>> 

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Vihanga Liyanage]

Hi all,

[Update]
I was able to complete the initial development of the proposed project,
encrypted id token support in OIDC flow. Following are the links related to
the development.

   - An issue was created in product-is repository to track the development.
  - https://github.com/wso2/product-is/issues/2336
   - Pull request is made to identity-inbound-auth-oauth repository with
   required updates.
   - https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/798
   - Pull request is made to product-is repository with updated playground
   application to test the feature
   - https://github.com/wso2/product-is/pull/2313
   - Code review was held to review the code written in both PRs.

All PRs are merged by now.
Currently, I'm working on integration test to test the newly added feature.

Thanks,
Vihanga

On Fri, Feb 9, 2018 at 5:07 PM, Vihanga Liyanage  wrote:

> Yes, Farasath. As for the offline discussions with Drashana, I came to the
> same conclusion and exploring the SAML sample app right now.
>
> Although I'm not sure about signing JWE. I couldn't find anything specific
> about that in the RFC. Also, the API in Nimbus only expects the claims set
> and the public key of the client to create and encrypt a JWE. Please do let
> me know if you find something else.
>
> On Fri, Feb 9, 2018 at 4:34 PM, Farasath Ahamed 
> wrote:
>
>>
>>
>> On Friday, February 9, 2018, Vihanga Liyanage  wrote:
>>
>>> [- Engineering, Strategy]
>>> [+ Architecture, Dev]
>>>
>>> Thanks,
>>> Vihanga
>>>
>>> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage 
>>> wrote:
>>>
 Hi Farasath,

 For the above two points IMO it would be better to provide an option at
> Service Provider OAuth/OIDC configuration. This will be similar to what we
> have done for SAML.
>

 That is the initial idea came to me as well. But shouldn't the clients
 have a choice of deciding that as well? May be through a request parameter.
 To use either JWS or JWE, the client have to support them right?

>>>
>> By enabling the option to encrypt id_token in the service provider
>> configs the client is acknowledging that it can support encrypted
>> id_tokens.
>>
>> AFAIK even for JWE we need to first sign and then encrypt. Also I
>> couldn't find any reference on a standard approach to allow clients to
>> switch between JWS and JWE via a request parameter.
>>
>> If we take a look at how we handle this is SAML, we have an option in the
>> SAML configs to say whether the assertion needs to be encrypted or not.
>> Once the option to encrypt assertion is enabled SAML assertions will always
>> be encrypted for the particular service provider (ie. There is no
>> requirement to switch between signed or encrypted assertions)
>>
>> IMO we can follow the same approach. WDYT?
>>
>>
> On a separate note, any specific reason why we are discussing this in
> strategy and not in Dev and architecture mailing lists?
>
> I feel that we need to discuss this feature in architecture mailing
> list to get the input from community.
>

 No such specific reason at all. On the previous project I did, the mail
 was asked to sent to engineering and strategy. So I followed the same
 protocol. I'll change that now.

>
>
>>
>> Thanks,
>> Vihanga.
>>
>> --
>>
>> Vihanga Liyanage
>>
>> Software Engineer | WS*O₂* Inc.
>>
>> M : +*94710124103* | http://wso2.com
>>
>> [image: http://wso2.com/signature] 
>>
>>
>> 
>>  Virus-free.
>> www.avast.com
>> 
>> <#m_-2123188955827273075_m_6964541531375253954_m_-4836321406318245336_m_-5520087002137875506_m_-4545884336410447238_m_682166417964237_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "WSO2 Engineering Group" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to engineering-group+unsubscr...@wso2.com.
>> For more options, visit https://groups.google.com/a/wso2.com/d/optout
>> .
>>
>
>
> --
> Farasath Ahamed
> Senior Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
>
>


 --

 Vihanga Liyanage

 Software Engineer | WS*O₂* Inc.

 M : +*94710124103* | http://wso2.com

 [image: http://wso2.com/signature] 

>>>
>>>
>>>
>>> --
>>>
>>> 

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Vihanga Liyanage]

Yes, Farasath. As for the offline discussions with Drashana, I came to the
same conclusion and exploring the SAML sample app right now.

Although I'm not sure about signing JWE. I couldn't find anything specific
about that in the RFC. Also, the API in Nimbus only expects the claims set
and the public key of the client to create and encrypt a JWE. Please do let
me know if you find something else.

On Fri, Feb 9, 2018 at 4:34 PM, Farasath Ahamed  wrote:

>
>
> On Friday, February 9, 2018, Vihanga Liyanage  wrote:
>
>> [- Engineering, Strategy]
>> [+ Architecture, Dev]
>>
>> Thanks,
>> Vihanga
>>
>> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage 
>> wrote:
>>
>>> Hi Farasath,
>>>
>>> For the above two points IMO it would be better to provide an option at
 Service Provider OAuth/OIDC configuration. This will be similar to what we
 have done for SAML.

>>>
>>> That is the initial idea came to me as well. But shouldn't the clients
>>> have a choice of deciding that as well? May be through a request parameter.
>>> To use either JWS or JWE, the client have to support them right?
>>>
>>
> By enabling the option to encrypt id_token in the service provider configs
> the client is acknowledging that it can support encrypted id_tokens.
>
> AFAIK even for JWE we need to first sign and then encrypt. Also I couldn't
> find any reference on a standard approach to allow clients to switch
> between JWS and JWE via a request parameter.
>
> If we take a look at how we handle this is SAML, we have an option in the
> SAML configs to say whether the assertion needs to be encrypted or not.
> Once the option to encrypt assertion is enabled SAML assertions will always
> be encrypted for the particular service provider (ie. There is no
> requirement to switch between signed or encrypted assertions)
>
> IMO we can follow the same approach. WDYT?
>
>
 On a separate note, any specific reason why we are discussing this in
 strategy and not in Dev and architecture mailing lists?

 I feel that we need to discuss this feature in architecture mailing
 list to get the input from community.

>>>
>>> No such specific reason at all. On the previous project I did, the mail
>>> was asked to sent to engineering and strategy. So I followed the same
>>> protocol. I'll change that now.
>>>


>
> Thanks,
> Vihanga.
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_6964541531375253954_m_-4836321406318245336_m_-5520087002137875506_m_-4545884336410447238_m_682166417964237_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> --
> You received this message because you are subscribed to the Google
> Groups "WSO2 Engineering Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to engineering-group+unsubscr...@wso2.com.
> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>


 --
 Farasath Ahamed
 Senior Software Engineer, WSO2 Inc.; http://wso2.com
 Mobile: +94777603866
 Blog: blog.farazath.com
 Twitter: @farazath619 
 





>>>
>>>
>>> --
>>>
>>> Vihanga Liyanage
>>>
>>> Software Engineer | WS*O₂* Inc.
>>>
>>> M : +*94710124103* | http://wso2.com
>>>
>>> [image: http://wso2.com/signature] 
>>>
>>
>>
>>
>> --
>>
>> Vihanga Liyanage
>>
>> Software Engineer | WS*O₂* Inc.
>>
>> M : +*94710124103* | http://wso2.com
>>
>> [image: http://wso2.com/signature] 
>>
>
>
> --
> Farasath Ahamed
> Senior Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
>
>


-- 

Vihanga Liyanage

Software Engineer | WS*O₂* Inc.

M : +*94710124103* | http://wso2.com

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Farasath Ahamed]

On Friday, February 9, 2018, Vihanga Liyanage  wrote:

> [- Engineering, Strategy]
> [+ Architecture, Dev]
>
> Thanks,
> Vihanga
>
> On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage  wrote:
>
>> Hi Farasath,
>>
>> For the above two points IMO it would be better to provide an option at
>>> Service Provider OAuth/OIDC configuration. This will be similar to what we
>>> have done for SAML.
>>>
>>
>> That is the initial idea came to me as well. But shouldn't the clients
>> have a choice of deciding that as well? May be through a request parameter.
>> To use either JWS or JWE, the client have to support them right?
>>
>
By enabling the option to encrypt id_token in the service provider configs
the client is acknowledging that it can support encrypted id_tokens.

AFAIK even for JWE we need to first sign and then encrypt. Also I couldn't
find any reference on a standard approach to allow clients to switch
between JWS and JWE via a request parameter.

If we take a look at how we handle this is SAML, we have an option in the
SAML configs to say whether the assertion needs to be encrypted or not.
Once the option to encrypt assertion is enabled SAML assertions will always
be encrypted for the particular service provider (ie. There is no
requirement to switch between signed or encrypted assertions)

IMO we can follow the same approach. WDYT?


>>> On a separate note, any specific reason why we are discussing this in
>>> strategy and not in Dev and architecture mailing lists?
>>>
>>> I feel that we need to discuss this feature in architecture mailing list
>>> to get the input from community.
>>>
>>
>> No such specific reason at all. On the previous project I did, the mail
>> was asked to sent to engineering and strategy. So I followed the same
>> protocol. I'll change that now.
>>
>>>
>>>

 Thanks,
 Vihanga.

 --

 Vihanga Liyanage

 Software Engineer | WS*O₂* Inc.

 M : +*94710124103* | http://wso2.com

 [image: http://wso2.com/signature] 


 
  Virus-free.
 www.avast.com
 
 <#m_-4836321406318245336_m_-5520087002137875506_m_-4545884336410447238_m_682166417964237_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

 --
 You received this message because you are subscribed to the Google
 Groups "WSO2 Engineering Group" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to engineering-group+unsubscr...@wso2.com.
 For more options, visit https://groups.google.com/a/wso2.com/d/optout.

>>>
>>>
>>> --
>>> Farasath Ahamed
>>> Senior Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>> 
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Vihanga Liyanage
>>
>> Software Engineer | WS*O₂* Inc.
>>
>> M : +*94710124103* | http://wso2.com
>>
>> [image: http://wso2.com/signature] 
>>
>
>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 

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

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Vihanga Liyanage]

[- Engineering, Strategy]
[+ Architecture, Dev]

Thanks,
Vihanga

On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage  wrote:

> Hi Farasath,
>
> For the above two points IMO it would be better to provide an option at
>> Service Provider OAuth/OIDC configuration. This will be similar to what we
>> have done for SAML.
>>
>
> That is the initial idea came to me as well. But shouldn't the clients
> have a choice of deciding that as well? May be through a request parameter.
> To use either JWS or JWE, the client have to support them right?
>
>>
>> On a separate note, any specific reason why we are discussing this in
>> strategy and not in Dev and architecture mailing lists?
>>
>> I feel that we need to discuss this feature in architecture mailing list
>> to get the input from community.
>>
>
> No such specific reason at all. On the previous project I did, the mail
> was asked to sent to engineering and strategy. So I followed the same
> protocol. I'll change that now.
>
>>
>>
>>>
>>> Thanks,
>>> Vihanga.
>>>
>>> --
>>>
>>> Vihanga Liyanage
>>>
>>> Software Engineer | WS*O₂* Inc.
>>>
>>> M : +*94710124103* | http://wso2.com
>>>
>>> [image: http://wso2.com/signature] 
>>>
>>>
>>> 
>>>  Virus-free.
>>> www.avast.com
>>> 
>>> <#m_-5520087002137875506_m_-4545884336410447238_m_682166417964237_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "WSO2 Engineering Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to engineering-group+unsubscr...@wso2.com.
>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>>
>>
>>
>> --
>> Farasath Ahamed
>> Senior Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 
>> 
>>
>>
>>
>>
>>
>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>



-- 

Vihanga Liyanage

Software Engineer | WS*O₂* Inc.

M : +*94710124103* | http://wso2.com

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture