Hi,
Please find my comments inline.
@Roshan, Yes that is the proper way of getting resource data according to
Richardson maturity model for REST APIs.We provide resource ID and do get
to fetch resource.
I think we may add it for users to get data later.
They can change grant types, scopes or app
As we discussed this endpoint will be secured with Basic Auth.
That means anyone who has login permission can create OAuth application in
system.
If need we may add special permission to create OAuth applications.
There is a profile called open registration for OAuth applications but its
vulnerabl
Hi Tharika,
Since *"**saasApp"* is not a common parameter as per the spec, you might
have to emphasise the usage of it.
Just noticed that in the excerpt you've provided request is sent to a
resource named oauthdcr. Better if we can name it as /regsiter to show the
conformity with the spec.
On Th
Hi Tharika,
+1. Have you thought about a way to fetch/update a DCR application?
There is a way you can achieve this by providing an access_token and
registration URL upon DCR registration. So then users can persist that
access_token and URL and can be used in future in order to edit the DCR
appl
Hi Tharika,
Have you decided on the security of this endpoint?
Thanks,
NuwanD.
On Thu, Feb 4, 2016 at 9:52 PM, Tharika Madurapperuma
wrote:
> Hi All,
>
> We are planning of $subject.
>
> In some use cases, it is desirable or necessary to allow OAuth clients to
> obtain authorization from an au
Hi All,
We are planning of $subject.
In some use cases, it is desirable or necessary to allow OAuth clients to
obtain authorization from an authorization server without the two parties
having previously interacted. Therefore in order for the authorization
server to accurately represent to end use