Our own apps will not run into this problem, but those who deploy APIM as a
PaaS or cloud offering may be faced with this problem from 3rd parties.
Apps would like to do this as well because it provides additional security
by revoking the associated tokens that were being used when the
registration is deleted.


For those who want to enforce a policy that require dynamic clients to be
temporary without depending on clients itself to remove their own
registrations, they will need to remove the corresponding SP from their end.

On 15 September 2016 at 12:36, Nuwan Dias <nuw...@wso2.com> wrote:

>
>
> On Thu, Sep 15, 2016 at 12:26 PM, Uvindra Dias Jayasinha <uvin...@wso2.com
> > wrote:
>
>> In the Cloud it could be API Creators, Publisher or Subscribers,
>> basically anyone who can call the REST API
>>
>
> So its the Store/Publisher webapps right? In that case it just creates 1
> client per app (2 in total) to be used by all who're logging into it. Can
> we really remove those clients? I think not. Because once you create them
> it has to be there for future use.
>
> I'm +1 to implement this as a feature but I don't recall an instance where
> our own Apps will end up creating 100s of clients through DCR. So at least
> for our own apps, they won't need to use this feature. For third party apps
> which may create many clients, unless those apps specifically call the
> removal operation, we'll still end up with lots of clients in the DB.
>
>>
>> On 15 September 2016 at 12:21, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>>
>>>
>>> On Thu, Sep 15, 2016 at 12:14 PM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
>>>> While using APIM's REST API Dynamic Client Registration(DCR) I noticed
>>>> that after registering a client there is no way for the client to remove
>>>> the registration entry. You need to provide a unique clientName in order to
>>>> register with the DCR[1]
>>>>
>>>> I think it might be good to provide this ability via the REST API.
>>>> Usually an App might create an entry for itself upon registration and
>>>> simply reuse that same entry. But there maybe scenarios where the
>>>> registration might be temporary only while using the API. At that point if
>>>> we dont provide a way of removing the registration this will continue to
>>>> remain in the database. If we think of the cloud scenario we could end up
>>>> with a large number of registration entries.
>>>>
>>>
>>> In the cloud scenario, who is the consumer of the DCR endpoint?
>>>
>>>>
>>>> Also currently if you want to change any of the information that you
>>>> send in the DCR request(callBackURL, tokenScope, grantType, etc) you have
>>>> no way of doing it if you have already registered. Providing an option of
>>>> removing the existing entry will solve this issue.
>>>>
>>>> WDYT?
>>>>
>>>>
>>>> [1] https://docs.wso2.com/display/AM200/apidocs/publisher/index.
>>>> html#guide, https://docs.wso2.com/display/
>>>> AM200/apidocs/store/index.html#guide
>>>>
>>>> --
>>>> Regards,
>>>> Uvindra
>>>>
>>>> Mobile: 777733962
>>>>
>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 777733962
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Regards,
Uvindra

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

Reply via email to