Tanya Vlahovic

Technologies are shown for network attribution tracking for a multi-legged transaction. In accordance with some aspects, a request is received at a second service from a client device via a first redirect including a first token associated with a first service. The second service sends, to a token service, a token request including the first token, wherein the token request causes the token service to associate a second token with the first token. The second service receives, from the token service, a token response including the second token. The second service provides, to the client device, a second redirect to a third service, the second redirect including the second token. In some aspects, a transaction is attributed to at least the first service and the second service based on the association of the second token with the first token.

Risk assessment in an authentication service is performed where an authorization request is received from a third-party application. Risk assessment policies for the authorization request are determined based on a class of the third-party application. The risk assessment policies are applied to the authorization request to determine an action to be performed for the authorization request, such as sending an authorization message in response to the authorization request or taking a remedial action (e.g., suspending the application, limiting the available actions, or sending a notification to a trusted security application).

Technologies are shown for trust delegation that involve receiving a first request from a subject client and responding by sending a first token having first permissions to the subject client. A second request from a first partner actor is received that includes the first token, and in response, the first partner actor is linked to the subject client in a trust stack and a second token is sent to the first actor with second permissions, the second token identifying the subject client and the first partner actor. A third request from a second partner actor is received that includes the second token, and in response, the second partner actor is linked to the first partner actor in the trust stack and a third token is sent to the second partner actor with third permissions, the third token identifying the first partner actor and the second partner actor.

Systems and methods for generating tokenized reputation scores are described. In one example, a service provider system receives data describing user activity associated with a service provider account and determines that the user activity is eligible for a reputation reward of reputation tokens. The service provider system initiates a calculation of the reputation reward based on the data describing the user activity. Further, the service provider system verifies a transfer of reputation tokens to a blockchain account address associated with the service provider account, where the reputation tokens are based on the reputation reward calculated. The service provider system generates a reputation score based on an amount of reputation tokens associated with the blockchain account address and generates an indication of the reputation score. The indication of the reputation score is displayed in relation to a representation of the service provider account.

Technologies are shown for network attribution tracking for a multi-legged transaction. In accordance with some aspects, a first token is provided to a first partner service. A token request is received from a second partner service, wherein the token request includes the first token. A second token is associated with the first token, and the second token is provided to the second partner service. A transaction is attributed to the first partner service and the second partner service based on the association of the second token with the first token.

The disclosure relates to a multi-legged network attribution using tracking tokens and attribution stack. Technologies are shown for network attribution tracking for a multi-legged transaction that involve receiving a tracking token registration request from a partner service, generating a tracking token associated with the partner service, adding an entry to an attribution stack for a transaction, where the entry associates the tracking token with the partner service, and returning the tracking token to the partner service. Receiving a tracking token request can include determining whether the tracking token request includes a previously generated tracking token and using the previously generated tracking token to identify the attribution stack for the transaction. Adding an entry to an attribution stack for a transaction can include adding the entry to the attribution stack identified for the transaction. Attribution for a transaction can be obtained by accumulating attribution entities from each entry in the attribution stack identified for the transaction.

Technologies are shown for trust delegation that involve receiving a first request from a subject client and responding by sending a first token having first permissions to the subject client. A second request from a first actor includes the first token and responding involves linking the first actor to the subject client in a trust stack and sending a second token to the first actor with second permissions, the second token being a first complex token that identifies the subject client and the first actor. A third request from a second actor includes the second token and responding to the third request involves linking the second actor to the first actor in the trust stack, and sending a third token to the second actor partner with third permissions, the third token being a second complex token that identifies the first actor and the second actor.

Risk assessment in an authentication service is performed where an authorization request is received from a third-party application. Risk assessment policies for the authorization request are determined based on a class of the third-party application. The risk assessment policies are applied to the authorization request to determine an action to be performed for the authorization request, such as sending an authorization message in response to the authorization request or taking a remedial action (e.g., suspending the application, limiting the available actions, or sending a notification to a trusted security application).

Technologies are shown for network attribution tracking for a multi-legged transaction that involve receiving a tracking token registration request from a partner service, generating a tracking token associated with the partner service, adding an entry to an attribution stack for a transaction, where the entry associates the tracking token with the partner service, and returning the tracking token to the partner service. Receiving a tracking token request can include determining whether the tracking token request includes a previously generated tracking token and using the previously generated tracking token to identify the attribution stack for the transaction. Adding an entry to an attribution stack for a transaction can include adding the entry to the attribution stack identified for the transaction. Attribution for a transaction can be obtained by accumulating attribution entities from each entry in the attribution stack identified for the transaction.

Technologies are shown for trust delegation that involve receiving a first request from a subject client and responding by sending a first token having first permissions to the subject client. A second request from a first actor includes the first token and responding involves linking the first actor to the subject client in a trust stack and sending a second token to the first actor with second permissions, the second token being a first complex token that identifies the subject client and the first actor. A third request from a second actor includes the second token and responding to the third request involves linking the second actor to the first actor in the trust stack, and sending a third token to the second actor partner with third permissions, the third token being a second complex token that identifies the first actor and the second actor.

Systems and methods for transforming an API authorization to a UX session are provided. An authorization server receives, from a third-party application developed by a third-party, a request to access a user experience (UX) session on behalf of a user. The request comprises an access token previously granted by the authorization server to the third-party application in response to consent, by the user, to allow the third-party application to perform actions on behalf of the user. In one embodiment, this previous authorization comprises an Open Authorization (OAuth). In response to receiving the request the authorization server transforms the access token into a single sign on (SSO) link with a session token. The authorization server then returns the SSO link that includes the session token the third-party application hosted by the third-party. The SSO link causes the third-party application to redirect the user to the UX session corresponding to the SSO link.

Technologies are shown for trust delegation that involve receiving a first request from a subject client and responding by sending a first token having first permissions to the subject client. A second request from a first actor includes the first token and responding involves linking the first actor to the subject client in a trust stack and sending a second token to the first actor with second permissions, the second token being a first complex token that identifies the subject client and the first actor. A third request from a second actor includes the second token and responding to the third request involves linking the second actor to the first actor in the trust stack, and sending a third token to the second actor partner with third permissions, the third token being a second complex token that identifies the first actor and the second actor.

Technologies are shown for application risk assessment in an authentication service where an authorization request is received from a third party application calling an Application Programming Interface (API). Risk assessment policies that pertain to behavioral characteristics, such as API usage patterns or past delegation of permissions, are applied to the authorization request to obtain a risk assessment score. If the risk assessment score does not exceed a risk threshold, then an authorization message is sent in response to the authorization request. If the risk assessment score exceeds the risk threshold, then remedial action, such as suspending the application, limiting the available actions, or sending a notification to a trusted security application, is executed for an account associated with the third party application. Machine learning can be applied to historical behavioral data to generate the risk assessment policies.

Systems and methods for transforming an API authorization to a UX session are provided. An authorization server receives, from a third-party application developed by a third-party, a request to access a user experience (UX) session on behalf of a user. The request comprises an access token previously granted by the authorization server to the third-party application in response to consent, by the user, to allow the third-party application to perform actions on behalf of the user. In one embodiment, this previous authorization comprises an Open Authorization (OAuth). In response to receiving the request the authorization server transforms the access token into a single sign on (SSO) link with a session token. The authorization server then returns the SSO link that includes the session token the third-party application hosted by the third-party. The SSO link causes the third-party application to redirect the user to the UX session corresponding to the SSO link.

Aspects of the present disclosure relate to a multi-dimensional commerce platform that may be utilized for the communication of data. Aspects of the multi-dimensional commerce platform may include various functional components to facilitate a system to receive inventory data at a first server associated with the multi-dimensional commerce platform, provide a second server associated with a third-party (e.g., a third party seller/distributor) access to the inventory data, alter or modify the inventory data based on attributes of the second server, and cause display of a presentation of the modified inventory data at a client device.

Technologies are shown for trust delegation that involve receiving a first request from a subject client and responding by sending a first token having first permissions to the subject client. A second request from a first actor includes the first token and responding involves linking the first actor to the subject client in a trust stack and sending a second token to the first actor with second permissions, the second token being a first complex token that identifies the subject client and the first actor. A third request from a second actor includes the second token and responding to the third request involves linking the second actor to the first actor in the trust stack, and sending a third token to the second actor partner with third permissions, the third token being a second complex token that identifies the first actor and the second actor.

Aspects of the present disclosure relate to a multi-dimensional commerce platform that may be utilized for the communication of data. Aspects of the multi- dimensional commerce platform may include various functional components to facilitate a system to receive inventory data at a first server associated with the multi-dimensional commerce platform, provide a second server associated with a third-party (e.g., a third party seller/distributor) access to the inventory data, alter or modify the inventory data based on attributes of the second server, and cause display of a presentation of the modified inventory data at a client device.