Dynamic authorization with adaptive levels of assurance

• US 10,572,874 B1
• Filed: 09/10/2017
• Issued: 02/25/2020
• Est. Priority Date: 03/29/2014
• Status: Active Grant

• Current Assignee: SecureAuth Incorporated
• Original Assignee: Acceptto Corporation
• Inventors: Shahidzadeh, Nahal, Akkary, Haitham
• Primary Examiner(s): Niquette, Robert R
• Assistant Examiner(s): Nguyen, Liz P
• Application Number:
  US15/700,153
• Time in Patent Office: 898 Days
• Field of Search: 705 44
• CPC Class Codes: G06Q 20/3821 Electronic credentials
• CPC Class Codes: G06Q 20/40 Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/0807 using tickets, e.g. Kerberos cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213
• CPC Class Codes: H04L 63/0861 using biometrical features, e.g. fingerprint, retina-scan cryptographic mechanisms or cryptographic arrangements for entity authentication using biological data H04L9/3231
• CPC Class Codes: H04L 63/20 for managing network security; network security policies in general filtering policies H04L63/0227
• CPC Class Codes: H04W 12/06 Authentication
• CPC Class Codes: H04W 12/68 Gesture-dependent or behaviour-dependent

Abstract

A system and method for issuing an authorization token and performing real time multi-factor authentication using a unique device or devices to enable authorization to perform secure services for an online service based on desired on demand level of assurance. The level of assurance of the authentication may be on a distributed and dynamic authenticated system. This dynamic system delivers on-demand level of assurance depending on the Relying Party'"'"'s (RP) requirements, orchestrated by policies set by the RP and/or the consumer (or user agent), and possibly augmented by other regulatory requirement based on a fine-grain control requirement of the authentication token(s). The level of assurance throttles up and down depending each transaction authentication requirement.

Claims

1. A method for authorizing a requested transaction from a Client Device during an active session, the method comprising:

receiving over a first secure communication channel, at a level of assurance (LOA) server having a secured configurable memory, a request from a Relying Party (RP) Services Application for the requested transaction from the Client Device;

determining, at the LOA Server, that the requested transaction requires a higher level of assurance than a current level of assurance associated with the active session of the Client Device based on i) new levels of service required by the requested transaction, or ii) different levels of risk calculated by a plurality of contextual identifiers based on a context of the Client Device, network or an LOA Provider device provisioned by the Client Device;

sending over a second secure communication channel, by the LOA Server, an authorization request for the requested transaction to the LOA Provider device, wherein the authorization request comprises information indicating a higher level of authorization credentials required for elevating the level of assurance of the active session;

receiving over a third secure communication channel, at the LOA Server, from the LOA Provider device at least one of a plurality of required authorization credentials including proximity of the LOA Provider to the Client Device for elevating the LOA associated with the active session;

determining, at the LOA Server, that the at least one of the plurality of authorization credentials received from the LOA Provider device is sufficient to elevate the active session to the higher LOA; and

sending authorization for servicing of the Client Device requested transaction to the RP Services Application.

2. The method of claim 1, wherein the LOA steps down to a lower level of assurance than the current LOA for the active session after completion of the transaction.

3. The method of claim 1, wherein the LOA steps down to a lower level of assurance during the active session after a predetermined time period.

4. The method of claim 1, wherein the required authorization credentials by the LOA Server depends on a risk assessment received from the Relying Party (RP) Server.

5. The method of claim 4, further comprising:

requesting by the LOA Server contextual factors from the LOA Provider device; and

wherein the plurality of contextual factors required by the LOA Server are stored at the LOA Server.

6. The method of claim 1 further comprising:

determining and requiring a different level of assurance for authorizing the transaction in real time from at least one of a group consisting of;

a Relying Party Server, the LOA Provider device, and the LOA Server.

7. The method of claim 1 further comprising:

inserting or removing required credentials at the LOA Server based on transaction credential and policies received from the RP Server; and

receiving a request from the RP Server having credentials and the LOA Provider device requirements and translating to an LOA requirement for the real time transaction authorization.

8. The method of claim 1, further comprising:

stepping up or down the LOA at the LOA Server based on at least one of the group of factors consisting of;

the transaction LOA demand, location change of the LOA Provider device, and change of connection type between the Client Device and the RP Server.

9. The method of claim 1, wherein the LOA Provider device is a mobile device.

10. The method of claim 1, wherein the LOA Server and the RP Server are the same device.

26. The method of claim 1 further comprising:

the level of assurance is stepped down due to increased distance of the LOA Provider device to the Client Device.

27. The method of claim 1 further comprising:

the level of assurance is stepped down due to overt intent initiated by the LOA Provider device.

28. The method of claim 1 wherein the proximity is established by a predetermined action of the LOA Provider device.

11. A method comprising:

receiving a request over a first secure communication channel for a Client Device registration of level of assurance (LOA) Provider device at an LOA Server having a secure configurable memory, said request for the Client Device registration including a plurality of attributes and credentials, wherein the attributes are at least a unique identification information associated with the Client Device and the credentials are at least unique information associated with the LOA Provider device;

identifying at the LOA Server the identity of the LOA Provider device by performing a plurality of verification steps on the plurality of attributes and credentials including proximity of the LOA Provider Device to the Client Device;

storing verified attributes and verified credentials at the LOA Server with a predetermined time to live value, wherein time to live is a predetermined time that the attributes or verified credentials are valid;

performing a refresh to at least some of the verified attributes and the verified credentials based on predetermined policies and on demand from a Relying Party Server;

receiving at the LOA server, a requested transaction from the Client Device;

determining, at the LOA Server, that the requested transaction requires a higher level of assurance than a current level of assurance associated with an active session of the Client Device based on i) new levels of service required by the requested transaction, or ii) different levels of risk calculated by a plurality of contextual identifiers based on a context of the Client Device, network or an LOA Provider device; and

sending authorization from the LOA Server for servicing of the higher level of assurance requested transaction to the Client Device.

12. The method of claim 11, wherein the predetermined policy includes information received from the LOA Provider device.

13. The method of claim 11, wherein the predetermined policy includes information received from the LOA Server or the RP Server.

14. The method of claim 11, further comprising:

managing at the LOA Server a window of validity for the transaction authorizations that determine their LOA and validity for a session or a transaction requiring the specific LOA.

15. The method of claim 11 wherein at least one of said plurality of verification steps includes receiving from the LOA Provider at least one of the plurality of attributes from the group consisting of:

unique LOA Provider user ID, a unique LOA Provider device ID, biometric information, spatial, and Contextual Identifiers including location and behavior.

16. A method for facilitating an interaction of a Level of Assurance (LOA) Server with a Relying Party (RP) Server in a sequence of transactions with different Levels of Assurance (LOA), said method comprising:

enrolling with the LOA Server having a configurable memory at least one of a plurality of LOA Provider devices associated with an entity;

uniquely identifying each of said entity enrolled LOA Provider devices to the RP Server;

receiving at the LOA Server from an entity Client Device authentication of the enrolled LOA Provider devices to approve a secure interaction between the Client Device and the RP Server;

authenticating at the LOA Server the Client Device up to a predetermined LOA using a plurality of contextual factors including proximity of the Client Device and at least one of the LOA Provider devices to be provided on demand from the at least one of the LOA Provider devices and sending real time authorization and authentication over a secure communication channel to the RP Server;

performing selective policy enforcement at the LOA Server on the LOA Provider devices based on criteria received from the Client Device, a desired LOA, and criteria set by the RP Server; and

selectively approving or denying interactions at the LOA Server for the RP Server for transactions.

17. The method of claim 16, wherein the criteria include a shared secret and encrypted contextual factors set by the RP Server based on the LOA required.

18. A method comprising:

authenticating at a Level Of Assurance (LOA) Server from an RP Service Application executing on a Client Device, over secure communication channels both an RP Server and an LOA Provider to enable an interaction based on a LOA;

receiving at the LOA Server a request from the Client Device to register the LOA Provider device, the request including a first unique identifier, said first unique identifier including at least one of a group consisting of;

a unique user identification, a unique identity of the person, an International Mobile Equipment Identity (IMEI), a phone number, and a first secret message;

receiving at the LOA Server over a secure communication channel from the LOA Provider device an LOA Provider registration message;

receiving at the LOA server a request from the RP Services Application a requested transaction;

determining, at the LOA Server, that a requested transaction requires a higher level of assurance than a current level of assurance associated with the active session of the Client Device based on i) new levels of service required by the requested transaction, or ii) different levels of risk calculated by a plurality of contextual identifiers based on a context of the Client Device, network or an LOA Provider device; and

sending authorization from the LOA Server for servicing of the higher level of assurance requested transaction to the RP Services Application.

19. The method of claim 18 further comprising:

sending to the LOA Provider device from the LOA Server the first secret message in a signed application that will use the first secret message as an initial seed to generate a second unique identifier.

20. The method of claim 18, wherein the LOA Provider registration message further comprises a second unique identifier, said second unique identifier including the first secret message, a LOA Provider unique ID and additional contextual factors.

21. The method of claim 18, wherein the authorization of the requested transaction is in real time or within a predetermined time allowed.

22. The method of claim 18, further comprising:

receiving at the LOA Server a request from the RP Server for a predetermined LOA to authorize a transaction;

sending a request from the LOA Server to the LOA Provider device; and

receiving from the LOA Provider authorization through additional factors approving the transaction based on the predetermined LOA.

23. The method of claim 22, wherein the additional factors includes contextual information from the group consisting of:

LOA Provider device location, biometric information, behavioral pattern, history, and environmental factors.

24. The method of claim 23, wherein the LOA Server based on LOA requirements of transaction requested by RP service demands stepping up the LOA and initialing a request for LOA provider device to provide authorization at higher level of assurance and then upon completion of transaction automatically stepping down to change LOA at the LOA Server to lower level during an active session.

25. The method of claim 18 further comprising:

temporarily or permanently un-registering or disabling an LOA Provider device at the LOA Server.