Hi Maduranga,
On Tue, Jan 23, 2018 at 10:23 AM, Maduranga Siriwardena <[email protected]>
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 <[email protected]>
> 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 <[email protected]> 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 <[email protected]>
>>> 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 <[email protected]>
>>>> 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 <
>>>>> [email protected]> 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] @
>>>>>> [email protected] 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": "[email protected]",
>>>>>> "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: [email protected]
>>>>>> 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
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Hasintha Indrajee
>>>> WSO2, Inc.
>>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [email protected]
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Maduranga Siriwardena
> Senior Software Engineer
> WSO2 Inc; http://wso2.com/
>
> Email: [email protected]
> Mobile: +94718990591 <+94%2071%20899%200591>
> Blog: *https://madurangasiriwardena.wordpress.com/
> <https://madurangasiriwardena.wordpress.com/>*
> <http://wso2.com/signature>
>
> _______________________________________________
> Dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
Thanks,
Omindu.
--
Omindu Rathnaweera
Senior Software Engineer, WSO2 Inc.
Mobile: +94 771 197 211
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
