Access control through strongly-typed dependent typing

Abstract

Systems and methods are described in which the burden of implementing access control policies, such that a computer user can access a restricted service under the control of the access control policies of an access-restricted system, is largely placed on the requesting user. More particularly, as part of a request user's request to access to a restricted service under the management of an access-restricted system, the requesting user, on the user's computing device, instantiates an access request object of a strongly-typed dependent access request type, where the access request type embodies one or more access control policies necessary to be permitted access. This transfers the burden of user validation to the user's computing device, leaving the access-restricted system to quickly determine the validity of a received access request object to determine whether to reject the request or process the access request.

Description

ACCESS CONTROL THROUGH STRONGLY-TYPED DEPENDENT TYPINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application also claims priority to U.S. Provisional Patent Application No.63 / 711,428, filed October 24, 2024, titled "Policy as Code, Access Control Through Dependent Typing," the entirety of which is incorporated herein by reference.BACKGROUND OF THE INVENTION

[0002] Wherever there are resources or services on a network that require protection, there is a need for access control policies, particularly policies to specify who can access those resources and what they can do with those resources, and processes to implement those access control policies. This protection may include what actions may be taken with respect to certain objects, as well as which parties may invoke certain methods. In short, wherever there are resources that must be managed, there is a need to have access policies that clearly identify who can do what and under which circumstances.

[0003] In current networked environments, access-restricted systems operating on the Internet are on their own to check and enforce applicable access policies. Unfortunately, this particular manner of enforcement places the overhead of access control policy implementation and enforcement on the access-restricted systems, particularly on the computer(s) and / or server(s) on which these systems operate. This enforcement burden is further heightened because each session requires the execution of the access policies, irrespective of whether a connecting user (referred to throughout as a requesting user) was vetted in an earlier session. This enforcement burden is further amplified by the fact that an access-restricted system is generally placed on a network to be accessed by multiple requesting users, meaning that the access-restricted systems are enforcing the policies for many requesting users, which makes significantly scaling up the amount of work to be difficult, if not impossible. Clearly, the burden of enforcing access policies (also referred to as access control) can be quite burdensome to any given access- restricted system.

[0004] In contrast to the standard practices of access control implementations, the disclosed subject matter sets forth an environment in which the burden of implementing access control policies, such that a computer user can access a restricted service under the control of an access-restricted system, is largely placed on the requesting user that tries to access to a restricted service under the management of an access-restricted system.SUMMARY OFTHE INVENTION

[0005] In accordance with aspects of the disclosed subject matter, systems and methods are described in which the burden of implementing access control policies, such that a computer user can access a restricted service under the control of the access control policies of an access-restricted system, is largely placed on the requesting user. More particularly, as part of a request user's request to access to a restricted service under the management of an access-restricted system, the requesting user, on the user's computing device, instantiates an access request object of a strongly-typed access request type, where the access request type embodies one or more access control policies necessary to be permitted access. This transfers the burden of user validation to the user's computing device, leaving the access-restricted system to quickly determine the validity of a received access request object to determine whether to reject the request or process the access request.

[0006] In accordance with additional aspects of the disclosed subject matter, a method for accessing a restricted service under the control of an access-restricted system is disclosed. As part of this method, access control policies of the access-restricted system are retrieved to a computer system of the requesting user for local use in generating an executable program that includes submitting an access request to interact with the restricted service. According to aspects of the disclosed subject matter, at least some policies of the access control policies are defined and implemented as strongly-typed type definitions. A set of coded instructions are generated, including at least one access request to a restricted service of the access-restricted system. The coded instructions corresponding to the at least one access request are embodied as an instantiation of a corresponding access request object, the access request object being a strongly-typed type. The set of coded instructions is then compiled, or where necessary otherwise converted, into an executable program. The compilation of the set of coded instructions, or a type-checking validation process on coded instructions that are not compiled, includes a successful validation evaluation of the coded instructions corresponding to the at least one access request, including the instantiation of the access request object. The result of a successful / satisfactory evaluation is that the coded instructions fully comply with the strongly-typed type definitions of the access control policies. So that the access- restricted system is able to determine whether a received access control object is fully compliant with its strongly-typed type definition, where the access control object comprises a packet of information including attributes and / or validated attribute pairs,validation data of compliance of the access control object, skeletal elements of proof regarding the attributes of the access control object, and the like. Execution of the executable program includes, at least, instantiating the access request object, and solely submitting the access request object for the restricted service to the access-restricted system.

[0007] In accordance with additional aspects of the disclosed subject matter, a computer-executable method implementing one or more aspects of an access-restricted system is presented. The method, in execution on a computer system including at least a processor, memory, and communication component, comprises receiving an access request, over a communication network from a computer associated with a requesting user, for a restricted service managed by the access-restricted system. The access request is embodied in an access request object, a packet comprising at least some of requisite attributes (including validated attribute pairs), a skeletal structure of the proof over the attributes, validation data, and an indication of the requested service for which the access request object was instantiated. After receiving the access request object, the access-restricted system conducts an evaluation of the validity of the access request object, i.e., a determination that the access request object comprises the required elements of a valid access request object. From a satisfactory determination that the access request object comprises the required elements of a valid access request object, a second evaluation is conducted to authenticate whether that the values of the fields of the access request object collectively prove compliance with a correspond access control policy of the restricted service. With the validity of the access request object determined, viewed as a SAT condition (i.e., the proof of validity is "SATisfied"), the access request is processed by the targeted restricted service. After the restricted service processing, return content (based on the processing of the restricted service) may be returned to the requesting user, or alternatively a SAT condition may be returned to the requesting user.BRIEF DESCRIPTION OF DRAWINGS

[0008] The foregoing aspects and many of the attendant advantages of the disclosed subject matter will become more readily appreciated as they are better understood by reference to the following description when taken in conjunction with the following drawings, wherein:

[0009] Figure 1 illustrates an exemplary sequential exchange over time between a requesting user (via the user's computing device) and an access-restricted system that implements access control polices, the exchange showing the validation effort / processing to validating the requesting user with the access-restricted system;

[0010] Figure 2 illustrates an alternative exemplary exchange between a requesting user (via the user's computing device) and an access-restricted system that implements access control policies, the exchange showing the validation effort / processing of validating the requesting user with the access-restricted system;

[0011] Figure 3 illustrates an exemplary exchange between a requesting user (via the user's computing device) and an access-restricted system that implements access control policies, the exchange showing the transfer of the validation effort / processing of requisite access control policies by the requesting user to the user's computing device;

[0012] Figure 4 is a flow diagram illustrating an exemplary routine, as implemented on a user computer, for requesting access to a restricted service of an access-restricted system that implements access control policies, all in accordance with aspects of the disclosed subject matter;

[0013] Figure 5 is a flow diagram illustrating an exemplary routine, as implemented by an access-restricted system that implements access control policies to one or more restricted services, for processing an access request from a requesting user for access to a restricted service of the one or more restricted services;

[0014] Figure 6 is a block diagram illustrating components of an exemplary user computing device for generating an access request for a restricted service of an access- restricted system, in accordance with aspects of the disclosed subject matter;

[0015] Figure 7 is a block diagram illustrating exemplary components of an access- restricted system that administers access control policies for one or more restricted services, all in accordance with aspects of the disclosed subject matter; and

[0016] Figure 8 is a block diagram illustrating exemplary computer-readable media suitable for hosting computer-executable instructions for generating an access request for a restricted service, and / or for implementing the various routines and process of an access-restricted system, all in accordance with aspects of the disclosed subject matter.DESCRIPTION OF THE INVENTION

[0017] By way of definition, "access control policies" are policies that defines who (or what) can access specific data, systems, services, and / or resources within an organization or managed by an access-restricted system, and under what conditions such access may be made. Thus, an "access-restricted system," is generally a network-accessible system that manages and / or administers access control via access control policies to one or more restricted services. Local access-restricted systems or libraries may also implement details of the disclosed subject matter.

[0018] The term "access request," for purposes of this document, is a computer- implemented request to communicatively interact with restricted service managed by an access-restricted system. An access request is embodied as an "access request object" that is communicatively sent to the restricted service, via the corresponding access- restricted system. As will be further described below, an access request object is a type- defined packet of one or more elements, including but not limited to validation data, attributes and / or validated attributes (where attributes are sometimes referred to as "claims", an indication of the restricted service that is for which access is requested, and skeletal elements of proof that the access request object satisfies a corresponding access control policy associated with he restricted service.

[0019] The phrase "solely submitting the access control object" should be understood to mean that the submission of a fully compliant access control object is the only interaction between the access-restricted system and the executable program for validating the requesting user's permission and access to the restricted service.

[0020] The terms "authentication," "authorization," and "validation" are frequently used, sometimes interchangeably in this document. To be clear, "authentication" with respect to a user, is determining or establishing the identity of that user. This of course, is important to access control policies that specify "who" is authorized by a policy. The term "authorization" is a question of "what," and is based on an authenticated "who". Authorization is a determination of whether the authenticated user has permission to carry out any specific action(s). And with respect to "validation," validation refers to whether a user is both authenticated and authorized to interact with a requested service. A validation evaluation typically returns one of two responses: SAT or satisfied if the user is authenticated and authorized; and UNSAT or unsatisfied if the user is either not authenticated or not authorized. Of course, the usual case is that if the user is notauthenticated, that cannot be authorized: there is no need to test for authorization of an unauthenticated person.

[0021] As indicated above, the disclosed subject matter transfers a significant portion of the burden of user authentication and compliance with an access control policy from the access-restricted system, which manages restricted services via one or more access control policies, to the requesting user, and more particularly to the compilation of executable code that makes the access request on the access-restricted system. In accordance with aspects of the disclosed subject matter, the executable code includes an instantiation of a strongly-typed and dynamic access request object type which serves as an access request to a restricted service and, if the instantiation of the access request object is proven valid by the system, the object also serves as evidence that the requesting user is authorized, according to the applicable access control policies, to access the restricted service for the purpose requested. For its part, the access restricted system carries out a determination that the access request object includes the requisite elements and further carries out a determination as to whether the values of the requisite elements comply with the access control policy associated with the restricted service.

[0022] Turning now to the figures, Figure 1 illustrates an exemplary sequential exchange 100 over time (indicated by the dashed arrows) between a requesting user (via the user's computing device) and an access-restricted system that implements access control policies, the exchange showing the validation effort / processing of validating the requesting user with the access-restricted systems. Indeed, this exemplary exchange may be viewed as a typical process currently in use when contacting access-restricted sites and systems.

[0023] Regarding this exchange and as shown in Figure 1, a request user 102, by way of the user's computing device 101, interacts with an access-restricted system 108 over a communication network 104, typically, though not exclusively, through an API 106 associated with the access-restricted system. As a first part of the exchange, the requesting user submits, via the requesting user's computing device 101, an access request 110 for access to a restricted service (not shown) of the access-restricted system 108.

[0024] In this exchange 100, the access-restricted system, which imposes access control policies for accessing restricted services, including the requested restricted service, must determine whether the requesting user has access to the service, and in many instances,whether the requesting user has permission to conduct specific actions with the restricted service, all of which must comply with one or more access control policies that the access-restricted system is imposing. To resolve the questions of who (authentication) and what (activity rights), the access-restricted system requests authentication information 112 from the requesting user. By way of illustration and not limitation, in some instances, this authentication information is a request for a username and a password / passcode, and for security may also include two factor authentication techniques. As will be readily appreciated, unfortunately these actions to comply with access control policies consume a significant amount of time, network and processing resources, all before the requesting user is granted (or denied) access to the restricted service.

[0025] In response to the request 112 of the access-restricted system, the requesting user 102, via the computing device 101, responds with the user's authentication credentials 114. Upon receiving the user's authentication credentials, the access- restricted system conducts an authentication and validation analysis 116 to determine whether or not the access request 110 is permitted according to the access control policies enforced by the access control system. Assuming that the user's access request is authenticated and access permissions are validated, the user's access request 110 is then advanced to the restricted service, where the request is, at last, processed 112. Thereafter, optionally a set of results 124 may be returned to the requesting user.

[0026] Clearly, unfortunately a significant amount of time, communication bandwidth and processing power are spent in ensuring that only authenticated and authorized requesting users who comply with one or more access control policies implemented by the access-restricted system, gain access to the requested restricted service. In fact, in many instances, the expenditure of resources on authenticating and authorizing a user according to access control policies is greater than the resource expenditure of processing the request by the restricted service. This resource expenditure is repeated for each session (once a session is established, authentication and validating authorization are often not required) of each requesting user has significant impact on the overall bandwidth of any given access-restricted system. To provide improved performance, those that implement the access-restricted systems allocate more resources for processing user requests. In short, in the described exchange 100, a significant burden of access control policing is carried by the access-restricted systems.While implementing access control policies is important, it has proven to be particularly costly.

[0027] Turning to Figure 2, this figure illustrates an alternative exemplary exchange 200 over time between a requesting user 102 (via the user's computing device 101) and an access-restricted system 108 that implements one or more access control policies, the exchange showing the validation effort / processing to validate the requesting user with the access-restricted system. As with Figure 1, this exemplary exchange 200 may be viewed as another typical process currently in use when contacting access-restricted sites and systems.

[0028] In this exchange 200, the access-restricted system 108, which imposes access control policies with respect to restricted services, including the restricted service of an access request 210, must determine whether the requesting user has access to the service, and in many instances, whether the requesting user has permission (authorization) to conduct specific actions with the restricted service, all of which must comply with one or more access control policies that the access-restricted system is imposing. In contrast to the exchange 100 of Figure 1, in the exchange 200 the access request 210 issued by the requesting user includes the requesting user's authentication credentials.

[0029] To resolve the questions of who (authentication) and what (activity rights), the access-restricted system requests authentication information 112 from the requesting user. By way of illustration and not limitation, in some instances, this authentication information is a request for a username and a password / passcode, and for security may also include two factor authentication techniques. As will be readily appreciated, unfortunately these actions to comply with access control policies consume a significant amount of time, network and processing resources, all before the requesting user is granted (or denied) access to the restricted service.

[0030] Even with the requesting user's authentication credentials, the access-restricted system may further proof of the user's identity / credentials and implement (not show) a second factor authentication (2FA) process. Of course, 2FA processes frequently require the use of a second communication network (or, at a minimum, additional consumption of bandwidth on the communication network 104) by sending a text message or requesting a validation code obtained from a trusted third party (e.g., from an authentication app on the requesting user's cell phone). These, of course, are examples of additional, often unseen, costs associated with implementing access control policies.

[0031] After receiving the requesting user's authentication credentials, and / or in conjunction with receiving the user's authentication credentials, the access-restricted system performs its access validation evaluation 212 to determine the authenticity of the requesting user and that the user's access request is aligned with the authorization of the requesting user with respect to the requested restricted service. In short, the access- restricted system 108 validates the requesting user with respect to the requested restricted service, to ensure that the request complies with existing access control policies associated with the restricted service.

[0032] In contrast to the common practices of validating user authentication and access authorization by an access-restricted system, the disclosed subject matter offloads a majority of the burden of access request validation to the requesting user. According to aspects of the disclosed subject matter, a set of access control policies implemented by the access-restricted system is made available to the requesting user. The set of access control policies include one or access control policies that have been translated into a strongly-typed type definition, which type definitions are instantiated and submitted to the access-restricted system as evidence of compliance with the access control policy of the type defined policy.

[0033] After validating the requesting user's access request with respect to the restricted service, and assuming that the requesting user's request has been satisfactorily validated, only then is the access request processed 214 by the requested restricted service. As illustrated in the exemplary exchange 200, after processing by the restricted service, access request results 216 are optionally returned to the requesting user. An alternative to access request results is the return of a SAT condition, indicating that the requested restricted service satisfactorily completed its process. Of course, in some instances, no return information, or no direct return information is provided.

[0034] In contrast to putting all access control policy compliance on the access- restricted system, and according to aspects of the disclosed subject matter, by the access-restricted system 108 sharing access control policy information with users, illustratively including user 102, a significant amount of access request validation, can be transferred onto a given requesting user. To further illustrate this, reference is now made to Figure 3.

[0035] Figure 3 illustrates an exemplary exchange 300 between a requesting user 102 (via the user's computing device 101) and an access-restricted system 108 that implements access control policies, the exchange showing the transfer of much of thevalidation effort / processing of one or more access control policies of a targeted restricted service, via in compilation and dynamic execution, from the access-restricted system to the user's computing device.

[0036] As a preliminary matter, the requesting user 102, via the user's computing device 101, requests access control policy information 302 of the access-restricted system 108. In various embodiments, the policy request is directed to an API function 304 of the access-restricted system's API 106, where the purpose of this API function is to provide structured interactions with the access-restricted system. Of course, in various embodiments, the access control policy information may be hosted on or by an alternative service or location on the network 104. Accordingly, the request specifically to the API function 304 should be viewed as illustrative and not limiting upon the disclosed subject matter.

[0037] With the shared access control policy information, and as an additional preparatory step in the exemplary exchange, the user generates a body of code, comprising various methods and procedure, that includes at least an instantiation of a strongly-typed and dependent access request type object, where the strongly-typed access request object, per its definition, implements at least one access control policy of the access-restricted system 108 required to access the restricted service. In various embodiments, the generated body of code is subsequently compiled on the requesting user's computing device and then executed, where the generation of code and the execution is illustrated as 308 in Figure 3. Of course, in some embodiments a translation of the body of code into executable tokens and / or script may occur.

[0038] Regarding the compilation of the body of code, it should be appreciated that a successful compilation of code based, at least in part, on the shared access control policy information, ensures that the executable code will correctly implement the access control policies. As the collection of the requisite attributes (as elements to an instantiation of an access request object), including user attributes, for inclusion in the instantiation of the access request object 308 is dynamically carried at execution time, in the event that the executing user is unable to supply the requisite attributes / value to the instantiation process, that instantiation process (which faithfully implements the corresponding access control policy (or policies) may or may not successfully instantiate. In some instances, validated attributes, comprising attribute information validated by a trusted third-party service, may be obtained for inclusion as an "attribute" in the access control object.

[0039] Those skilled in the art will appreciate that the dynamic instantiation of the access request object is the execution of a proposition as defined by the access control policy for accessing the restricted service. This proposition can be thought of as: "if the executing user provides a set of attributes which satisfy at least one path to compliance with the access control policy, the access request object will be instantiated." While not shown if Figure 3, if the user is unable to supply the required elements / attributes, often obtained from third parties, the access request object is not generated by the dynamic instantiation call, instead resulting in an UNSAT (UNSATisfied) condition. In some embodiments, including where third parties supply information directly to the access- restricted system rather than to the requesting user, one or more attributes of the access request object may indicate a third-party source for obtaining a particular attribute / credential of the requesting user, and the access-restricted service may execute its own sidecar process to obtain that information. Of course, in conditions where the attempt to obtain the attributes needed from these third party sources fail, that failure results in an UNSAT condition and the access request fails. As suggested above, in environments where there is no compilation of code, the code instructions are processed through a strong type-checking evaluation (not shown in Figure 3) to determine an appropriate instantiation of an access request object.

[0040] According to aspects of the disclosed subject matter and as suggested above, the dynamic execution of the compiled code instantiates an access request object according to the strongly-typed and dependent access request type definition using one or more required attributes (perthe propositional requirements of the access control policies of the access request) of the executing user and submits this access request object 310 to the access-restricted system 108. In various embodiments, the access request object may be directed to the access-restricted system 108 via a specific API function 312 of the access-restricted system's API 106.

[0041] According to aspects of the disclosed subject matter, and as will be discussed in greater detail below, the instantiation, with an accompanying indication, often of a trusted third party process, of a proper instantiation of an access request object of the strongly-typed access request definition, the object is submitted as proof that the requesting user has complied with an access control policy to access the restricted service. Simply put, an instantiation of the access request object embodies the work of obtaining the user attributes and qualifications required to comply with the one or moreaccess request policies with respect to interaction with the restricted service implemented by the access-restricted system.

[0042] Regarding the receipt of the access control object by the access-restricted system, it should be appreciated that, to the access-restricted system, any submission for access to its restricted services over the network 104 must be viewed as an untrusted submission and, as such, the access-restricted system must take measures to ensure that the access request object is authentic, and that it contains the attribute necessary to satisfy at least one path of satisfactory compliance with the corresponding access control policy corresponding to the restricted service.

[0043] Upon receipt of the access control object, and since trust must be established for the object, a process - sometimes referred to as a "sidecar" process - performs a first validation, referred to in Figure 3 as the authenticate process 312. This authenticate process evaluates the received access request object to ensure that the object includes the attributes / elements specified for the access control policy information for that object. All or some of the attributes may be validated attributes (having a validation element and the attribute data). It may also include a verification value, a cypher, from a third party service or application, that the object was instantiated in compliance with the access control policy corresponding to the restricted service.

[0044] A second process, referred to as the authenticate attributes process 314, ensures that the various attribute values, as well as the cypher value of the object, are authentic, and that the provided elements collectively prove compliance with the corresponding access control policy. Failure to authenticate either process will result in an UNSAT condition and deny access, as shown in Figure 3. Advantageously, the burden of gathering user credentials, determining their compliance with the access control police, and reducing them to values in an access request that prove compliance with the corresponding access control policy, is shouldered by the user computer.

[0045] While not shown, in some embodiments of the disclosed subject matter, an access-restricted system may have additional, unpublished internal validation processes that are executed upon receipt of an access request object. Of course, due to their internal, unpublished nature, this internal process cannot be pushed off to the requesting user's computing device 101. Other than any internal and / or unpublished process the access-restricted system must take, this leaves the relatively simple and quickly resolved authentication processes 312 and 314 to the access-restricted system as the gatekeeping processes to the restricted service.

[0046] After determining the authenticity of the received access request, and as a function of receiving an authentic access request object whose existence can be proved to embody at least one path of compliance of the one or more access control policies relating to the restricted service, the access-restricted system passes on (or carries out) the access request to the restricted service, where the request is processed 316. As with the other implementations described above, there may optionally be returned data from the restricted service, as indicated by the access request results 318, as a SAT condition, or no return of any kind may be made or expected.

[0047] As can be seen in this illustrative exchange 300, a significant amount of work is transferred from the access-restricted system 108 to the computing device 101 of the requesting user. This represents a significant savings in resource bandwidth and processing power, freeing the access-restricted system to more efficiently and quickly direct authentic requests to the corresponding restricted services, assured that the compliance with one or more corresponding access control policies has already and dynamically been enforced.

[0048] With respect to performing the access control policy(ies) implementation to carry out an access request on an access-restricted service, reference is now made to Figure 4. Indeed, Figure 4 is a flow diagram illustrating an exemplary routine 400, as implemented on a user computer, such as user computer 101, for generating and, through execution, dynamically requesting access to a restricted service of an access-restricted system 108 that implements one or more access control policies with respect to the restricted service, all in accordance with aspects of the disclosed subject matter.

[0049] At block 402, and as part of generating executable code to interact with the restricted service, information for implementing the access control policies of the access- restricted system is obtained. According to aspects of the disclosed subject matter, this information includes one or more strongly-typed dependent type definitions of corresponding access control policies implemented by the access-restricted system, including at least one strongly-typed dependent type definition that implements an access control policy of the access-restricted system, including a strongly-typed dependent type definition to request access / interaction with the restricted service. In various embodiments, in addition to strongly-typed dependent type definitions, other data in the information may include libraries necessary to instantiate a strongly-typed dependent type definition in the information, libraries and or links to third party services(trusted by the access-request system) to validate whether coded instructions fully comply with and satisfy a corresponding access control policy, and the like.

[0050] At block 404, coded instructions are generated. These coded instructions include, at least, instructions for instantiating and submitting an access request object, the access request object being an instance of a strongly-typed and dependent access request type defined in the access information from the access-restricted system.

[0051] In accordance with one or more embodiments of the disclosed subject matter, a code development language that supports dependent (which is viewed as including / subsuming strong typing) constructs are used to generate all or some of the coded instructions. In one embodiment, the programming language, Agda, is used due to its ability to support policies, including access control policies, as logical statements over attributes, where the policies are actually dependent and strongly typed types in the language. This type of support creates a sense of greater guarantee of authenticity and validity, and includes compile-time rule checking for correctness, generates regression proofs (as opposed to regression tests), and has the ability to prove properties and compliance of a given policy. Further, the code for instantiating the access request object includes accepting one or more attributes of the submitting user, the values to be dynamically determined at the time of execution, which also corresponds to the time of instantiation of the access request object. Additionally, the generated code for instantiating the access control object may correspond to a call to a routine residing in a library provided with the access control policy information and includes code that provides a validation cypher indicating that the access control object was properly instantiated. In some embodiments, the validation field / cypher may be provided by a trusted (trusted by the access-restricted system 108) third-party service, either as a library, an online service call, or code associated with the instantiation.

[0052] Assume that access to a restricted service is governed by an access control policy:only authenticated users that are members of one of three groups of authorized groups, e.g., Groups A, B and C, can access the restricted service. So, the user must submit a valid access request object (satisfactorily instantiated from a strongly-typed type definition) as a claim of validity to access the restricted service. The access request object has two elements: dynamic authentication data of the requesting user; and dynamic validation data that the user is a member of one of Groups A, B or C. Each of these two subattributes, themselves, require strict adherence to strongly-typed type definitions. Both may be validated elements, i.e., the trustworthiness of the element / attribute data isvalidated by a trusted third-party module, and correspondingly, each element includes a cypher generated by the trusted third-party module. These attribute cyphers typically, though not exclusively, comprise a digital signature or the like, the is trustable evidence to the access-restricted service that the element / attribute data is valid.

[0053] Continuing the example, assume that to generate a user authentication object, the user executes a program that includes an instantiation of the object request one of three types of instantiations: an authentication indication from a trusted (to the access- restricted system) third-party, e.g., via a one-time password authentication process; a biometric authentication of the user by a trusted application; or a strong password. During execution / instantiation, the user may be presented with an option for performing one of the three processes. Advantageously, the user computer, at execution time (ensuring dynamic authentication), carries out the processing effort involved with authenticating the user. Assuming that the user properly (i.e., satisfactorily) authenticated themselves via one of the acceptable methods (according to the type definition), an authentication object would be instantiated, the authentication object including at least a cypher / validation field (providing the authentication object was validly generated), proof data identifying the proof elements (not the entire proof structure) or paths to determining authentication of the user, and potentially some additional data that is unique to the user.

[0054] In continuance of the example, and assuming a satisfactory authentication of the user, the authentication object is then passed as data to an "authorized group" instantiation, which determines by some trusted means that the user is a member of one of Groups A, B or C. A satisfactory instantiation results in the "authorized group" results in an object that includes the validation field (validating a strongly-typed authentically / validly instantiated "authorized group" object), proof data identifying the proof elements or paths to determining authentication membership in one of Groups A, B or C, and any other data regarding the membership, all according to the type definition.

[0055] In continuation of the example, with both the authentication of the user (a resulting authentication object) and the authentication of the user as a member of an "authorized group" (the resulting authorized group object), the instantiation of the access request object would include a validation field, proof elements (these include the user authentication object and the "authorized group" object), and any additional data and / or records that should be included for a validly instantiated access request object.

[0056] According to various embodiments of the disclosed subject matter, at block 406, an evaluation of adherence to the strong typing of the instantiation of the access request object is likely made. Using strongly-typed languages, this adherence is most likely ensured. Dependent on the nature of the body of coded instructions, this evaluation may be carried out within the compilation of the coded instructions as most compiler / compilation processes include a type-checking evaluation. However, in circumstances where no strong typing is carried out as part of the compilation process, a type-adherence evaluation is carried out, independent to prior to translation to an executable format, and especially prior to execution, to ensure that the any call to instantiate the access control object complies with the strongly- typed and dependent type definitions that are required in order to access the restricted service.

[0057] At block 408, an optional step of compiling the body of coded instructions into an executable form is carried out. As indicated, this may correspond to taking text (coded instructions) and generating executable code to carry out the instructions embodied in the text / coded instructions. In other embodiments, this may comprise translating the coded instructions into computer-interpretable tokens to carry out the logic embodied in the coded instructions. Of course, in some instances, e.g., coded instructions written as script, no additional translation may be necessary such that a "compilation" is an optional step of routine 400.

[0058] At block 410, the executable code is generated and, in the course of executing a dynamic instantiation process, if the dynamic instantiations of the various type definitions are successful, which results in the instantiation of the access request object, and in block 412 the user can submit that access request object to the access-restricted system to access the restricted service. The access request object is evidence (validity fields and proof elements) of the validity of the access request and compliance with access control policies associated with the restricted service. This solely leaves the task of determining the validity of the access request object to the access-restricted system. Thereafter, the routine 400 terminates.

[0059] Advantageously, as the instantiation of the access request object is dynamic, the executable code may be saved for execution at another time. On the other hand, validation of an object implementing an access control policy, such as the exemplary access request object, may reflect a version of the shared information for implementing the access control policies of the access-restricted system is no longer up-to-date. Thiswould require obtaining the latest version of shared information, potentially regenerating the body of code instructions and recompiling the code instructions.

[0060] Ultimately, through strongly-typed dependent type definitions, the processing and resource costs associated with validating compliance with access control policies of an access-restricted system are transferred to the request user 102 / user computer 101.

[0061] Turning now to Figure 5, Figure 5 is a flow diagram illustrating an exemplary routine 500, as implemented by an access-restricted system 108, which system administers access control policies to one or more restricted services, for processing an access request. Beginning at block 502, the access-restricted system receives an access request for a restricted service in the form of a strongly-typed access request object as defined in the shared access control policy information regarding the system's access control policies.

[0062] At block 504, and as the access request object is not considered trustworthy until proven trustworthy, the access-restricted system 108 executes an authentication request 312 that authenticates / validates that the received access request object was properly instantiated and includes the attributes / elements that are needed to prove authentication and authorization of the request. This may also include determining, based on a validation portion (e.g., a digital signature of a trusted third party) that the paired attribute value is genuine. Of course, this testing of the validation portion of a validated attribute may be carried out with respect to the authentication of an attribute's value to ensure attribute compliance with the access control policy. As discussed above, this determines whether the received object includes the elements necessary to be a valid access request object. The validation / cypher field may be checked to ensure the received record's authenticity, as well as verifying the presence of the requisite fields to prove it as a valid request.

[0063] At block 506, the access-restricted system 108 executes an authenticate attributes process 314 that determines whether the values included in the received object can prove, collectively, compliance with the corresponding access control policy. As shown in routine 500, failure to authenticate either authentication request process 312 or authenticate attributes process 314 results in an UNSAT condition and access to the restricted service is not permitted.

[0064] At block 508, any authentication processes that are internal, unpublished and / or private to the access-restricted system 108 is optionally carried out, reliant of course, on the attributes and / or validated attributes of the access request object. In short, anyadditional, internal authentication process relies upon the attributes already provided and is not burdened with the responsibility to obtain additional authentication information from the requesting user. This, of course, does not preclude the access- restricted service from obtaining authentication or validation information from one or more trusted third-party services. Of course, as illustrated in routine 500, an UNSAT condition from any of the evaluation processes of blocks 504-508 will result in the routine 500 proceeding to block 514 where, optionally, an UNSAT value may be returned to the requesting user and the routine 500 would terminate.

[0065] Assuming a SAT condition of the validation evaluations of blocks 504-508, the access-restricted system now trusts that the requesting user complies with the system's access control policies, and having determined that the access request object is valid, at block 510 the system processes the access request via the requested restricted service. After processing the request, at block 512, the access-restricted service (or the restricted service) may optionally return data, a SAT condition, or nothing at all. Thereafter, the routine 500 terminates.

[0066] As can be seen with a comparison and consideration of routines 400 and 500, the use of strongly-typed and dependent type definitions is effectively used to transfer the processing and resource costs of validating user compliance with access control policies to a requesting user, such as user 102 via the user's computer 101.

[0067] Turning now to Figure 6, this figure is a block diagram illustrating components of an exemplary user computing device 600 for generating an access request for a restricted service of an access-restricted system, in accordance with aspects of the disclosed subject matter. The computing device 600, typical to most computing devices, includes a processer 604 to execute computer-executable instructions, a memory 608 and / or a user data store 618, and a communication component 606.

[0068] Suitable computing devices include, by way of illustration and not limitation, desktop and laptop computers, tablet computer systems, handheld mobile computing devices, online computing platforms (often referred to as cloud computing services), distributed computing devices / computers, and the link. As those skilled in the art will appreciate, the memory 604, includes both transitory memory, used by the computer system to hold and execute commands, make calculations, and store data, as well as long term memory or storage where data is stored in a non-transitory manner. The user data store 618 typically, though not exclusively, stores data, files, executable objects, and the like on a more permanent basis - similar to the non-transitory memory except save andretrieve times are typically much slower, and the size of the data store is typically significantly larger than non-transitory memory.

[0069] The communication component 606 comprises both hardware and software to provide a communication channel between the computing device 600 and external services, such as access-restricted system 108 of Figure 3, over a network 104.

[0070] In addition to the components described above, the computing device 600 may typically store the shared information of the access-restricted system, illustrated as files of strongly-typed type definition records 616. This information includes the definition of dynamic types (strongly-typed) that implement one or more access control policies of the access-restricted system with respect to restricted services managed by the system.

[0071] A compiler 610 is that executable program or module that converts the code instructions to "executable" content, i.e., content that can be executed (interpretation, execution of binary code, running of one or more scripts, and the like) to generate an access request on the access-restricted service. The ACP (access control policy) modules 612 are modules (even helper modules) that may be located locally on the computing device 600 that may assist in the dynamically instantiation of strongly-typed and dependent type objects, and generating validation information for instantiated objects that comply with the one or more access control policies of the access-restricted system 108. The validation modules 614 include those modules that are used to evaluate the validity of code instructions, as described above.

[0072] In operation, the above described modules operate to offload the costs of processing and resources regarding the authentication of users, the validation of requests, and the implementation of access control policies from the access-restricted system to the computing device 600.

[0073] Turning to Figure 7, is a block diagram illustrating exemplary components of an access-restricted system 700 that administers access control policies for one or more restricted services, all in accordance with aspects of the disclosed subject matter.Typically, though not exclusively, the access-restricted system is implemented on one or more servers 720 available over a network, on a cloud-computing device, a virtual server system comprising a plurality of distributed devices, or the like. However, as with most computing devices, the access-restricted system's computer system will include at least a processer 702 to execute computer-executable instructions, a memory 704 and / or a data store 718, and a communication component 706.

[0074] The communication component 706, in similar manner to the communication component 606 described above, comprises both hardware and software to provide a communication channel between the access-restricted system 700 and other devices such as the computing device 600, over a communication network 104.

[0075] Also included in the exemplary access-restricted system 700 is shared access control policy information 716, i.e., the shared information provided to computing devices to enable them to perform user authentication and request validation on the user computing device, in accordance with the access control policies represented by the type definitions in the share information, freeing the access-restricted system 700 of that burden.

[0076] The authenticate record component 710 is that component that evaluates and determines that the received access request object is properly formed: i.e., determines that the attributes / elements required for this access request object are present, as discussed above with respect to authentication request process 312.

[0077] The access-restricted system also controls and / or manages the restricted services 712 by administering access control policies. Of course, this management also includes providing shared information to the user computing devices and having the various typed objects corresponding to access control policies generated on the "client side."

[0078] Still further the authenticate attributes component 714 validates and determines that the attributes / elements of the received record, collectively, prove compliance with at least one path of an access control policy of the request service. All or some of shared helper modules and libraries 722, and other important data may be stored in the data store 718.

[0079] Turning now to Figure 8, Figure 8 is a pictorial diagram of a representation 800 of computer-readable media 806 bearing computer-executable instructions for carrying out various aspects of the disclosed subject matter.

[0080] As will be appreciated by those skilled in the art, computer-readable media 800, which includes, by way of illustration and not limitation, one or more of: a CD-R disc, a DVD-R disc, a platter of a hard disk drive, and / or an SSD device. In various embodiments, computer-readable media is encoded computer- readable data 806, including executable programs, data, libraries and the like, including content for generating access policy compliant objects as described above, and / or implementing the various features of an access-restricted system. This computer-readable data 806 in turn comprises a set of computer-executableinstructions 804 as well as data. For purposes of the disclosed subject matter, computer-readable media should be interpreted as non-transitory data storage devices.

[0081] Other non-limiting examples of a computer-readable medium (or media) include optical media (e.g., compact discs, "CDs", in various writable and / or non- writable forms, digital versatile discs, "DVDs" in their various writeable and / or non-writable forms, etc.), solid-state devices (e.g., USB "thumb" drives, flash memory cards or devices, etc.), magnetic discs and tapes, read-only cartridge devices, hard drives, and the like.

Claims

AMENDED CLAIMS received by the International Bureau on 19 May 2026 (19.05.2026)1. A method for accessing a restricted service of an access-restricted system, the method comprising: accessing, via a computer of a requesting user over a computer network, shared access control policies implemented by the access restricted system, wherein at least some of the shared access control policies are defined and implemented through strongly-typed type definitions; via execution by the computer associated with the requesting user: validating a set of code instructions that include an instantiation of an access request object of a strongly-typed access request type defined in the shared access control policies, to satisfactorily determine that the set of code instructions fully comply with the shared access control policies; wherein valid instantiation of an access request object of the strongly-typed access request type represents authentication of a requesting user and authorization of the requesting user to access the restricted service; executing an executable program based on the set of code instructions, the execution of the executable program comprising, at least: instantiating a strongly-typed access request type access request object according to one or more attributes of the requesting user necessary to prove compliance with at least one path of one of the shared access control policies, wherein the instantiated access request object comprises a validation cypher field for validating that the access request object was validly instantiated according to the shared access control policy, and further comprises at least some of the one or more attributes corresponding to the requesting user necessary to demonstrate compliance with at least one path of an access control policy for accessing the restricted service; submitting the access request object to a trusted validation service of the access-restricted system for validation that the access request object was validly instantiated according to the at least one access control policy; obtaining a digital cypher indicating that the access request object was validly instantiated and storing the digital cypher in the validation cypher field; andsubmitting the access request object to the access restricted system as authentication and authorization for accessing the access-restricted service.

2. The method of Claim 1, wherein satisfactorily evaluating that the set of coded instructions fully complies with the strongly-typed access request type defined in the shared access control policies is carried out by a process other than the compiler.

3. The method of Claim 1 wherein the one or more attributes are required attributes corresponding to the requesting user that satisfactorily comply with an access control policy for accessing the restricted service.

4. The method of Claim 3 wherein the instantiated access request object further comprises a set of proof elements of at least one access control policy that demonstrate a satisfactory compliance path of the at least one for accessing the restricted service.

6. The method of Claim 1, further comprising compiling the set of coded instructions into the executable program, the executable instructions including instructions to dynamically instantiate an access request object and submit the access request object to the access- restricted system for access to the restricted service.

7. A computer-implemented system for accessing a restricted service of an access-restricted system, the computer implemented system comprising, at least, a processor, a memory, and a communication module for communicating over a communication network, and wherein the computer implemented system is configured to implement any one of the methods of Claim 1 through Claim 4 and Claim 6.

8. A computer-readable medium bearing computer-executable instructions which, when executed on a computing device comprising, at least, a process, a memory, and a communication module for communicating over a communication network, carry out any one of the methods of Claim 1 through Claim 4 and Claim 6.

9. A computer-implemented method implementing one or more aspects of an access-restricted system, comprising at least: receiving, over a communication network, an access request object from a computing device associated with a computer user to access a restricted service, wherein access to the restricted service is restricted by at least a first access control policy of a plurality of shared access control policies implemented by the access-restricted system; authenticating that the access request object comprises the required elements of a valid access request object; upon satisfactorily authenticating that the access request object comprises the required elements of a valid access request object for the restricted service, satisfactorily authenticating that the values of the elements of the access request object collectively prove compliance with a corresponding access control policy of the restricted service; and subsequent to authenticating that the access request object comprises the required elements of a valid access request object and satisfactorily authenticating that the values of the fields of the access request object collectively prove compliance with the correspond access control policy of the restricted service, processing the access request via the restricted service.

10. The computer-implemented method of Claim 9, further comprising, prior to processing the access request via the restricted service: validating that the values of the elements of the access request object collectively prove compliance with a corresponding access control policy of the restricted service according to one or more internal validation processes of the access-restricted system with respect to the access control policy corresponding to the restricted service.

11. The computer-implemented method of Claim 9, wherein: the instantiated access request object comprises a record validation field and one or more attributes corresponding to the requesting user, the record validation field comprising acypher that can tested to determine that the access request object complies with the strongly- typed access request type defined in the shared access control policies; and wherein the one or more attributes are required attributes corresponding to the requesting user that satisfactorily comply with an access control policy for accessing the restricted service.

12. The computer-implemented method of Claim 11, wherein the access request object further comprises a set of proof elements that demonstrate a satisfactory compliance path, based on the one or more attributes corresponding to the requesting user, of the access control policy for accessing the restricted service.

13. The computer-implemented method of Claim 9, wherein: a first attribute of the one or more attributes corresponding to the requesting user is a validated attribute comprising a validation field; the validation field of the validation attribute includes a validation cypher of a trusted third party of the access-restricted service; and attribute data of the first attribute is data corresponding to the requesting user from the trusted third party.

14. A computer-implemented system implementing one or more aspects of an access-restricted system, the computer implemented system comprising, at least, a processor, a memory, and a communication module for communicating over a communication network, and wherein the computer implemented system is configured to implement any one of the methods of Claim 9 through Claim 13.

15. A computer-readable medium bearing computer-executable instructions which, when executed on a computing device comprising, at least, a process, a memory, and a communication module for communicating over a communication network, carry out any one of the methods of Claim 9 through Claim 13.

Images