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

[Maduranga Siriwardena]

Now the problem is how these claims are returned. If you configure security
questions for a user, when the user information is exported, below is the
data sent with the current implementation.

"basic":{
  "http://wso2.org/claims/userid":"a42b7c0a-ae21-46c9-bb78-3bfeb8e7625c;
,
  "http://wso2.org/claims/username":"admin;,
  "http://wso2.org/claims/created":"2018-02-08T14:34:06Z;,
  "http://wso2.org/claims/role":"Internal/everyone,admin;,
  *"http://wso2.org/claims/challengeQuestion2
"*:
"Model of your first car ?!jhcb4EciCCjfWfAd5tfR24vpYzE93ahv6REJQ8uZFW0=",
  "http://wso2.org/claims/fullname":"admin;,
  "http://wso2.org/claims/modified":"2018-02-08T14:34:06Z;,
  *"http://wso2.org/claims/challengeQuestion1
"*:
"City where you were born ?!YPWTFQ5dt0xLWKAkEQoQy/AEakfIYIBlwaWKgOO23YI=",
  "http://wso2.org/claims/emailaddress":"ad...@wso2.com;,
  "http://wso2.org/claims/lastname":"admin;,
  *"http://wso2.org/claims/challengeQuestionUris
"*:"
http://wso2.org/claims/challengeQuestion1!http://wso2.org/claims/challengeQuestion2
",
  "http://wso2.org/claims/givenname":"admin;
   }

Note the claims marked in red color above. Though the value of these claims
makes sense inside the identity server, they might not make sense once they
are exported.

And in the same time, these claims are a separate category of claims. So if
we can divide them to separate categories, it would make much sense in my
opinion. What would be the best way to achieve this?


On Fri, Feb 9, 2018 at 11:18 AM, Ruwan Abeykoon  wrote:

> Hi Maduranga,
> I consider anything related to user as PI.
> So security questions and answers also falls into this. We need to send
> these even if we keep them hashed (the hash value)
>
> Cheers,
> Ruwan
>
> On Fri, Feb 9, 2018 at 11:12 AM, Maduranga Siriwardena  > wrote:
>
>> Do we need to add security related information of the user also to the
>> response?
>>
>> For example the security questions configured by the user
>>
>> Thanks,
>>
>> On Thu, Feb 8, 2018 at 12:02 PM, Maduranga Siriwardena <
>> madura...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> Based on the discussions had offline we did few changes to the api. We
>>> have come up with 3 endpoints.
>>>
>>> /api/identity/user/v1.0/me
>>> Get the personal information of authenticated user.
>>>
>>> /api/identity/user/v1.0/pi-info/{userId}
>>> Get the personal information of the user with the given id. Users with
>>> "administrative" privileges can invoke this api. We need to decide what
>>> level authorization needed for this operation.
>>>
>>> /api/identity/user/v1.0/pi-info?username=
>>> Get the user ids and usernames of the given username pattern. This might
>>> not be implemented at the moment.
>>>
>>> Thanks,
>>> Maduranga.
>>>
>>> On Wed, Jan 24, 2018 at 8:33 PM, Isura Karunaratne 
>>> wrote:
>>>


 On Wed, Jan 24, 2018 at 2:20 PM, Maduranga Siriwardena <
 madura...@wso2.com> wrote:

> 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.
>

 Yes. We can use the same application.

>
> [1] https://github.com/wso2-extensions/identity-governance/t
> ree/v1.0.38/components/org.wso2.carbon.identity.user.endpoint
>
> Thanks,
>
> On Tue, Jan 23, 2018 at 10:40 AM, Maduranga Siriwardena <
> madura...@wso2.com> 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}


 IMO  we can use following format,

 / t/{tenant-domain}/api/identity/user/v1.0/pi-info/{id}


 Thanks
 Isura.

>
 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

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

[Ruwan Abeykoon]

Hi Maduranga,
I consider anything related to user as PI.
So security questions and answers also falls into this. We need to send
these even if we keep them hashed (the hash value)

Cheers,
Ruwan

On Fri, Feb 9, 2018 at 11:12 AM, Maduranga Siriwardena 
wrote:

> Do we need to add security related information of the user also to the
> response?
>
> For example the security questions configured by the user
>
> Thanks,
>
> On Thu, Feb 8, 2018 at 12:02 PM, Maduranga Siriwardena  > wrote:
>
>> Hi all,
>>
>> Based on the discussions had offline we did few changes to the api. We
>> have come up with 3 endpoints.
>>
>> /api/identity/user/v1.0/me
>> Get the personal information of authenticated user.
>>
>> /api/identity/user/v1.0/pi-info/{userId}
>> Get the personal information of the user with the given id. Users with
>> "administrative" privileges can invoke this api. We need to decide what
>> level authorization needed for this operation.
>>
>> /api/identity/user/v1.0/pi-info?username=
>> Get the user ids and usernames of the given username pattern. This might
>> not be implemented at the moment.
>>
>> Thanks,
>> Maduranga.
>>
>> On Wed, Jan 24, 2018 at 8:33 PM, Isura Karunaratne 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 24, 2018 at 2:20 PM, Maduranga Siriwardena <
>>> madura...@wso2.com> wrote:
>>>
 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.

>>>
>>> Yes. We can use the same application.
>>>

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

 Thanks,

 On Tue, Jan 23, 2018 at 10:40 AM, Maduranga Siriwardena <
 madura...@wso2.com> 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}
>>>
>>>
>>> IMO  we can use following format,
>>>
>>> / t/{tenant-domain}/api/identity/user/v1.0/pi-info/{id}
>>>
>>>
>>> Thanks
>>> Isura.
>>>

>>> 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 <
>>> hasin...@wso2.com> 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.

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

[Maduranga Siriwardena]

Do we need to add security related information of the user also to the
response?

For example the security questions configured by the user

Thanks,

On Thu, Feb 8, 2018 at 12:02 PM, Maduranga Siriwardena 
wrote:

> Hi all,
>
> Based on the discussions had offline we did few changes to the api. We
> have come up with 3 endpoints.
>
> /api/identity/user/v1.0/me
> Get the personal information of authenticated user.
>
> /api/identity/user/v1.0/pi-info/{userId}
> Get the personal information of the user with the given id. Users with
> "administrative" privileges can invoke this api. We need to decide what
> level authorization needed for this operation.
>
> /api/identity/user/v1.0/pi-info?username=
> Get the user ids and usernames of the given username pattern. This might
> not be implemented at the moment.
>
> Thanks,
> Maduranga.
>
> On Wed, Jan 24, 2018 at 8:33 PM, Isura Karunaratne  wrote:
>
>>
>>
>> On Wed, Jan 24, 2018 at 2:20 PM, Maduranga Siriwardena <
>> madura...@wso2.com> wrote:
>>
>>> 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.
>>>
>>
>> Yes. We can use the same application.
>>
>>>
>>> [1] https://github.com/wso2-extensions/identity-governance/t
>>> ree/v1.0.38/components/org.wso2.carbon.identity.user.endpoint
>>>
>>> Thanks,
>>>
>>> On Tue, Jan 23, 2018 at 10:40 AM, Maduranga Siriwardena <
>>> madura...@wso2.com> 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}
>>
>>
>> IMO  we can use following format,
>>
>> / t/{tenant-domain}/api/identity/user/v1.0/pi-info/{id}
>>
>>
>> Thanks
>> Isura.
>>
>>>
>> 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 <
 hasin...@wso2.com> 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 

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

[Maduranga Siriwardena]

Hi all,

Based on the discussions had offline we did few changes to the api. We have
come up with 3 endpoints.

/api/identity/user/v1.0/me
Get the personal information of authenticated user.

/api/identity/user/v1.0/pi-info/{userId}
Get the personal information of the user with the given id. Users with
"administrative" privileges can invoke this api. We need to decide what
level authorization needed for this operation.

/api/identity/user/v1.0/pi-info?username=
Get the user ids and usernames of the given username pattern. This might
not be implemented at the moment.

Thanks,
Maduranga.

On Wed, Jan 24, 2018 at 8:33 PM, Isura Karunaratne  wrote:

>
>
> On Wed, Jan 24, 2018 at 2:20 PM, Maduranga Siriwardena  > wrote:
>
>> 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.
>>
>
> Yes. We can use the same application.
>
>>
>> [1] https://github.com/wso2-extensions/identity-governance/t
>> ree/v1.0.38/components/org.wso2.carbon.identity.user.endpoint
>>
>> Thanks,
>>
>> On Tue, Jan 23, 2018 at 10:40 AM, Maduranga Siriwardena <
>> madura...@wso2.com> 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}
>
>
> IMO  we can use following format,
>
> / t/{tenant-domain}/api/identity/user/v1.0/pi-info/{id}
>
>
> Thanks
> Isura.
>
>>
> 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 <
>>> hasin...@wso2.com> 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 <
 omi...@wso2.com> wrote:

> Hi Maduranga,
>
> In the consent API we do not have the option to get multiple

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

[Isura Karunaratne]

On Wed, Jan 24, 2018 at 2:20 PM, Maduranga Siriwardena 
wrote:

> 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.
>

Yes. We can use the same application.

>
> [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 <
> madura...@wso2.com> 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}


IMO  we can use following format,

/ t/{tenant-domain}/api/identity/user/v1.0/pi-info/{id}


Thanks
Isura.

>
 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 

Re: [Dev] [Architecture] 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: [Dev] [Architecture] Personal information export API

[Maduranga Siriwardena]

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
>>>provided to the Identity Server. Though in the swagger it is 
>>> represented
>>>with the ID of the consent receipt, the actual response will consist 
>>> of the
>>>whole consent receipt. (Refer mail thread [2] @
>>>architect...@wso2.org for more information)
>>>
>>> Below is a sample JSON response.
>>>
>>> {
>>>   "basic": {
>>> "http://wso2.org/claims/userid": "92d6513e-f4ca-4438-b403-98380
>>> 695ed08",
>>> "http://wso2.org/claims/username": "maduranga",
>>> "http://wso2.org/claims/givenname": "Maduranga",
>>> "http://wso2.org/claims/lastname": "Siriwardena",
>>> "http://wso2.org/claims/emailaddress": "madura...@wso2.com",
>>> "http://wso2.org/claims/telephone": "+947
>>> 

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

[Omindu Rathnaweera]

Hi Maduranga,

On Tue, Jan 23, 2018 at 10:23 AM, Maduranga Siriwardena 
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.


>
> 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
>>provided to the Identity Server. Though in the swagger it is 
>> represented
>>with the ID of the consent receipt, the actual response will consist 
>> of the
>>whole consent receipt. (Refer mail thread [2] @
>>architect...@wso2.org for more information)
>>
>> Below is a sample JSON response.
>>
>> {
>>   "basic": {
>> "http://wso2.org/claims/userid": "92d6513e-f4ca-4438-b403-98380
>> 695ed08",
>> "http://wso2.org/claims/username": "maduranga",
>> "http://wso2.org/claims/givenname": "Maduranga",
>> "http://wso2.org/claims/lastname": "Siriwardena",
>> "http://wso2.org/claims/emailaddress": "madura...@wso2.com",
>> "http://wso2.org/claims/telephone": "+947
>> <+94%2071%20111%20>"
>>   },
>>   "consents": [
>> {
>>   "id": "bc53e7bd-013d-4020-b522-1915ada1f305"
>> }
>>   ]
>> }
>>
>> Do you have any suggestions for additional types of information to be
>> included in the response?
>>

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

[Maduranga Siriwardena]

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.

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
>provided to the Identity Server. Though in the swagger it is 
> represented
>with the ID of the consent receipt, the actual response will consist 
> of the
>whole consent receipt. (Refer mail thread [2] @
>architect...@wso2.org for more information)
>
> Below is a sample JSON response.
>
> {
>   "basic": {
> "http://wso2.org/claims/userid": "92d6513e-f4ca-4438-b403-98380
> 695ed08",
> "http://wso2.org/claims/username": "maduranga",
> "http://wso2.org/claims/givenname": "Maduranga",
> "http://wso2.org/claims/lastname": "Siriwardena",
> "http://wso2.org/claims/emailaddress": "madura...@wso2.com",
> "http://wso2.org/claims/telephone": "+947
> <+94%2071%20111%20>"
>   },
>   "consents": [
> {
>   "id": "bc53e7bd-013d-4020-b522-1915ada1f305"
> }
>   ]
> }
>
> Do you have any suggestions for additional types of information to be
> included in the response?
>
> [1] https://app.swaggerhub.com/apis/Maduranga/PersonalInform
> ationExport/1.0.0
> [2] Consent Management APIs for IS 5.5.0
>
> Thanks,
>
> --
> Maduranga Siriwardena
> Senior Software Engineer
> WSO2 Inc; http://wso2.com/
>
> Email: madura...@wso2.com
> Mobile: +94718990591 <+94%2071%20899%200591>
> Blog: *https://madurangasiriwardena.wordpress.com/
> 

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

[Hasintha Indrajee]

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
provided to the Identity Server. Though in the swagger it is represented
with the ID of the consent receipt, the actual response will consist of 
 the
whole consent receipt. (Refer mail thread [2] @
architect...@wso2.org for more information)

 Below is a sample JSON response.

 {
   "basic": {
 "http://wso2.org/claims/userid": "92d6513e-f4ca-4438-b403-98380
 695ed08",
 "http://wso2.org/claims/username": "maduranga",
 "http://wso2.org/claims/givenname": "Maduranga",
 "http://wso2.org/claims/lastname": "Siriwardena",
 "http://wso2.org/claims/emailaddress": "madura...@wso2.com",
 "http://wso2.org/claims/telephone": "+947
 <+94%2071%20111%20>"
   },
   "consents": [
 {
   "id": "bc53e7bd-013d-4020-b522-1915ada1f305"
 }
   ]
 }

 Do you have any suggestions for additional types of information to be
 included in the response?

 [1] https://app.swaggerhub.com/apis/Maduranga/PersonalInform
 ationExport/1.0.0
 [2] Consent Management APIs for IS 5.5.0

 Thanks,

 --
 Maduranga Siriwardena
 Senior Software Engineer
 WSO2 Inc; http://wso2.com/

 Email: madura...@wso2.com
 Mobile: +94718990591 <+94%2071%20899%200591>
 Blog: *https://madurangasiriwardena.wordpress.com/
 *
 

>>>
>>>
>>>
>>> --
>>> Omindu Rathnaweera
>>> Senior Software Engineer, WSO2 Inc.
>>> Mobile: +94 771 197 211 <077%20119%207211>
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
>


-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[Ruwan Abeykoon]

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
>>>provided to the Identity Server. Though in the swagger it is represented
>>>with the ID of the consent receipt, the actual response will consist of 
>>> the
>>>whole consent receipt. (Refer mail thread [2] @ architect...@wso2.org
>>>for more information)
>>>
>>> Below is a sample JSON response.
>>>
>>> {
>>>   "basic": {
>>> "http://wso2.org/claims/userid": "92d6513e-f4ca-4438-b403-98380
>>> 695ed08",
>>> "http://wso2.org/claims/username": "maduranga",
>>> "http://wso2.org/claims/givenname": "Maduranga",
>>> "http://wso2.org/claims/lastname": "Siriwardena",
>>> "http://wso2.org/claims/emailaddress": "madura...@wso2.com",
>>> "http://wso2.org/claims/telephone": "+947
>>> <+94%2071%20111%20>"
>>>   },
>>>   "consents": [
>>> {
>>>   "id": "bc53e7bd-013d-4020-b522-1915ada1f305"
>>> }
>>>   ]
>>> }
>>>
>>> Do you have any suggestions for additional types of information to be
>>> included in the response?
>>>
>>> [1] https://app.swaggerhub.com/apis/Maduranga/PersonalInform
>>> ationExport/1.0.0
>>> [2] Consent Management APIs for IS 5.5.0
>>>
>>> Thanks,
>>>
>>> --
>>> Maduranga Siriwardena
>>> Senior Software Engineer
>>> WSO2 Inc; http://wso2.com/
>>>
>>> Email: madura...@wso2.com
>>> Mobile: +94718990591 <+94%2071%20899%200591>
>>> Blog: *https://madurangasiriwardena.wordpress.com/
>>> *
>>> 
>>>
>>
>>
>>
>> --
>> Omindu Rathnaweera
>> Senior Software Engineer, WSO2 Inc.
>> Mobile: +94 771 197 211 <077%20119%207211>
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[Hasintha Indrajee]

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  > 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
>>provided to the Identity Server. Though in the swagger it is represented
>>with the ID of the consent receipt, the actual response will consist of 
>> the
>>whole consent receipt. (Refer mail thread [2] @ architect...@wso2.org
>>for more information)
>>
>> Below is a sample JSON response.
>>
>> {
>>   "basic": {
>> "http://wso2.org/claims/userid": "92d6513e-f4ca-4438-b403-98380
>> 695ed08",
>> "http://wso2.org/claims/username": "maduranga",
>> "http://wso2.org/claims/givenname": "Maduranga",
>> "http://wso2.org/claims/lastname": "Siriwardena",
>> "http://wso2.org/claims/emailaddress": "madura...@wso2.com",
>> "http://wso2.org/claims/telephone": "+947
>> <+94%2071%20111%20>"
>>   },
>>   "consents": [
>> {
>>   "id": "bc53e7bd-013d-4020-b522-1915ada1f305"
>> }
>>   ]
>> }
>>
>> Do you have any suggestions for additional types of information to be
>> included in the response?
>>
>> [1] https://app.swaggerhub.com/apis/Maduranga/PersonalInform
>> ationExport/1.0.0
>> [2] Consent Management APIs for IS 5.5.0
>>
>> Thanks,
>>
>> --
>> Maduranga Siriwardena
>> Senior Software Engineer
>> WSO2 Inc; http://wso2.com/
>>
>> Email: madura...@wso2.com
>> Mobile: +94718990591 <+94%2071%20899%200591>
>> Blog: *https://madurangasiriwardena.wordpress.com/
>> *
>> 
>>
>
>
>
> --
> Omindu Rathnaweera
> Senior Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211 <077%20119%207211>
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev