Abstract: A message is received, that represents an action to be performed in a service. The message includes a natural language portion and an endpoint to interact with. The natural language portion is parsed to identify the action and the endpoint is interacted with to perform the action.

Abstract: Activating an extension includes opening a first compose application by a first computing device. A composed document is received, and an extension is activated in response to the document. The extension may be activated as the document is being composed.

Abstract: Activating an extension includes opening a first compose application by a first computing device. A composed document is received, and an extension is activated in response to the document. The extension may be activated as the document is being composed.

Abstract: Activating an extension includes opening a first compose application by a first computing device. A composed document is received, and an extension is activated in response to the document. The extension may be activated as the document is being composed.

Abstract: A message is rendered in an email inbox, with a user actuable element. User actuation is detected and an endpoint associated with the user actuable element is interacted with to perform an action in a service from within the email inbox.

Abstract: A message is received, that represents an action to be performed in a service. The message includes a natural language portion and an endpoint to interact with. The natural language portion is parsed to identify the action and the endpoint is interacted with to perform the action.

Abstract: Activating an extension includes opening a first compose application by a first computing device. A composed document is received, and an extension is activated in response to the document. The extension may be activated as the document is being composed.

Abstract: Activating an extension includes opening a first compose application by a first computing device. A composed document is received, and an extension is activated in response to the document. The extension may be activated as the document is being composed.

Abstract: An abstraction for one or more commands associated with a client application may be received upon deployment of a host application. The abstraction may be an extension with a same package and code such that the extension is enabled across a variety of platforms, host applications, and devices. For example, the extension may be displayed through a user interface of the host application based on definitions contained within the abstraction such that the extension is compatible with a platform and device on which the host application is deployed. The commands may be translated into graphical control elements, and displayed in conjunction with the extension based on the definitions. Upon invocation of one or more of the commands, an action may be performed based on the definitions enabling the client application to interact with content being created, edited, and/or viewed in the host application in an appropriate context.

Abstract: A system-enforced two party verification process is described. An action to be taken on a resource is permitted when that resource is tagged with a same code by both a service vendor and the customer to whom the resource is associated. The system issues the code to the service vendor and relies on the service vendor to provide the code to the customer. The system then permits the action to be taken on the resource or automatically causes the action to be taken upon receipt of the code being applied by the customer to the same resource as previously indicated by the service vendor.

Abstract: Activating an extension includes opening a first compose application by a first computing device. A composed document is received, and an extension is activated in response to the document. The extension may be activated as the document is being composed.

Abstract: Role-based security architecture that facilitates delegated role assignments where role functionality is monotonically decreasing. In furtherance thereof decreasing monotonicity roles are arranged in a hierarchy. Moreover, delegated roles can be obtained by creating a derived role (from a parent role) and removing entries from the derived role to decrease the permissions for the derived role. Delegated role assignments are scoped (bounded), which automatically applies a given scope to the assignment created by the user receiving the delegation.

Abstract: Architecture that provides centrally located role-based administration where role assignments that are used to calculate scopes for each operation and create a filtered request that only returns objects that the user is allowed to manage. No access checks are needed. The architecture addresses the proliferation of scope definitions by at least creating a set of relative scopes such as that can generically apply to multiple users at once. More specifically, self-relative scopes and absolute scopes are provided.

Abstract: Recovery action approval may be provided. A request to perform an action may be received from a user. If the user is not always authorized to request the action, then the action may be performed if a policy rule permits the user to request the action.

Abstract: Architecture removes the limitation of a fixed set of roles and scopes, allows more effective permission auditing, and provides a convenient delegation model. Administrators can create roles fine-tuned to business needs without changing permissions on the resources. The new roles can be easily examined and delegated to other administrators. Moreover, scoping and delegation is simplified. This is possible because permissions are granted as a role (a unit of permission assignment is a role), which can include multiple entries. The entries correspond to end-user actions and are not related to implementation-dependent resource rights. The actions can include web services or API calls, script or executable file names, specialized commands that implement particular operation, and associated parameters, etc., essentially any action that the end-user performs.

Abstract: Architecture that creates a class of role-based scopes that can be declared “exclusive”, which automatically means that no user can access the scope unless the user is granted that exact scope. The exclusive scope excludes an object from the new scopes and existing scopes. In other words, the exclusive scope is a write restriction from a domain scope. The exclusive scope denies user access unless the user is granted the exclusive scope. The exclusive scope can be applied to a group of user objects. The exclusive scope is explicitly assigned to the object to grant access to an exclusive group. Moreover, the exclusive scope is immediately write-protected upon creation.

Abstract: Architecture that creates a class of role-based scopes that can be declared “exclusive”, which automatically means that no user can access the scope unless the user is granted that exact scope. The exclusive scope excludes an object from the new scopes and existing scopes. In other words, the exclusive scope is a write restriction from a domain scope. The exclusive scope denies user access unless the user is granted the exclusive scope. The exclusive scope can be applied to a group of user objects. The exclusive scope is explicitly assigned to the object to grant access to an exclusive group. Moreover, the exclusive scope is immediately write-protected upon creation.

Abstract: A role-based access control (RBAC) for the administration of complex services, such as for messaging. The RBAC architecture facilitates the creation of a role mechanism that describes any end-user, administrator, or partner action, of a set of scopes that address all populations, and a single authorization mechanism to handle role assignments through various mechanisms. Moreover, role and scope concepts are provided that universally apply to various management scenarios. A common set of primitives is defined that represent actions of enterprise and tenant end-users, partners, tenant administrators, datacenter administrators, and enterprise administrators. The primitives can include actions, action parameters, and API calls. Additionally, a set of scopes is defined that include self-relative scopes for end-users and tenants, and, absolute and filter-based scopes for administrators.

Abstract: Architecture that provides centrally located role-based administration where role assignments that are used to calculate scopes for each operation and create a filtered request that only returns objects that the user is allowed to manage. No access checks are needed. The architecture addresses the proliferation of scope definitions by at least creating a set of relative scopes such as that can generically apply to multiple users at once. More specifically, self-relative scopes and absolute scopes are provided.

Abstract: Architecture removes the limitation of a fixed set of roles and scopes, allows more effective permission auditing, and provides a convenient delegation model. Administrators can create roles fine-tuned to business needs without changing permissions on the resources. The new roles can be easily examined and delegated to other administrators. Moreover, scoping and delegation is simplified. This is possible because permissions are granted as a role (a unit of permission assignment is a role), which can include multiple entries. The entries correspond to end-user actions and are not related to implementation-dependent resource rights. The actions can include web services or API calls, script or executable file names, specialized commands that implement particular operation, and associated parameters, etc., essentially any action that the end-user performs.