On Tue, Jan 23, 2018 at 10:35 AM, Omindu Rathnaweera <omi...@wso2.com>
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 <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 <ruw...@wso2.com> 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
>>>>>> 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] @
>>>>>>>    architecture@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": "+94711111111
>>>>>>> <+94%2071%20111%201111>"
>>>>>>>   },
>>>>>>>   "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/
>>>>>>> <https://madurangasiriwardena.wordpress.com/>*
>>>>>>> <http://wso2.com/signature>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Omindu Rathnaweera
>>>>>> Senior Software Engineer, WSO2 Inc.
>>>>>> Mobile: +94 771 197 211 <077%20119%207211>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@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
>>>>> d...@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Hasintha Indrajee
>>> WSO2, Inc.
>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> 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/
>> <https://madurangasiriwardena.wordpress.com/>*
>> <http://wso2.com/signature>
>>
>> _______________________________________________
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
> Thanks,
> Omindu.
>
> --
> Omindu Rathnaweera
> Senior Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211 <+94%2077%20119%207211>
>



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

Email: madura...@wso2.com
Mobile: +94718990591
Blog: *https://madurangasiriwardena.wordpress.com/
<https://madurangasiriwardena.wordpress.com/>*
<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to