While a full description of OATH is way beyond what I can do in this quick blog entry, I wanted to talk a bit about how "SCOPES" interact with the already rich authorization model used by Domino.

Thanks to the fantastic work by John Curtis and his team, the node.js integration with Domino is going to be getting a rich security model. What we know is that a user's authorizations will be respected through the node.js application to the Domino server -- including reader names, ACLs, Roles, and so on. The way that will be done is an "OAUTH" authentication and authorization model.

To understand why this is important, you need to realize that the node.js application is a separate thing from the Domino server itself. Each node "Application" will have it's own credentials to access the services you create and publish in Domino. Consider the following applications:

Node Application 1 is an interactive cafeteria menu application. The daily menu is stored in a domino database called "menus.nsf". Most users have read access to this, but a few of them have author access to create each day's menu. The node.js application also has a feedback area, and it interacts with "cafFeedback.nsf". Users have depositor access there.

Node Application 2 is an HR system that lets users change their tax status for their payroll. It interacts with "payroll.nsf".

In a traditional Domino environment, users would log on to the Domino server and no matter which application they used, it would be done under the same access credentials.

In a Node.js aplication, it is the APPLICATION that first needs access to the Domino resources, and then it needs to do things in Domino on your behalf. That's what OAUTH does. OAUTH allows you to create a sort of passkey that allows the cafeteria application to access the Domino server under your credentials, without actually giving your password to that application. The same is true for the payroll application.

With OAUTH scopes, you'll be giving the cafeteria application the authority to act on behalf of a user in the "menus.nsf" and the "cafFeedback.nsf" but no where else. The Cafeteria application's ability to act on behalf of users under their credentials does not extend to using those same credentials in the "payroll.nsf" application or in their mail file or anywhere else that is out of SCOPE for the Cafeteria application. The APP has its own limits regardless of what user is using the app. User limits are still respected within the scope the application has access to.

I hope this helps make scopes a bit more clear.