Maybe the SCOPE's should be more specific per API. Currently we have API's
like 'account', 'transfer' and 'atm'. The SCOPE could refer to them such
as 'SCOPE=account transfer atm'.
This would also allow SCOPE's for the time where WRITE operations come
In the call yesterday, Sascha pointed out that the users at least want to know whether it will be read only or read-write. Does that imply that we need a structured scope ?
So when write operation is needed .. I am thinking wAccount or WCustomer???
Actually, there can be several types of "write" operation, are there not?
I wonder if we should have separate scopes for Create, Update, and Delete.
Yes there are various of operation similar to CRUD can be done for given entity (Account or transaction) . There are features as well such as transfer, billpay.
I think the problem is that we will end up very fast with a huge list of "small" scopes. I have seen that in a project I was working on.
I think when we refer to "read" it is straight forward, reading the account balance for example. But "write"? What is written to an account? A new account alias as "My empty account"?
It is probably important to come up with a list of actions that could be taken on typical bank entities such "account" or "customer". Once that list is complete we should be able to categorize what actions can be taken and then we can come up with a list of (not too many) scope's.
@SaschaZeGerman Agreed. From the customer's point of view, unlike "read", "write" is way too abstract. It should be tied to the use cases rather than the data models, I suppose.