Claims:What is claimed is:
1. A computer-implemented method, comprising:
receiving, by one or more processors, at a computer Application, responsible for Authentication and Authorization of Users, a request for a Authentication Token from a First User, identified by a User Identifier such as email or National ID number;
Authenticating the First User based a plurality of mechanisms like userid/password combination, OAUTH or Multi Factor Authentication;
providing, by the one or more processors, a secure signed Authentication Token such as Jason Web Token (JWT) specific to the authenticated First User;
further receiving a message by the said First User via a URL request, comprising of:
the received JWT Token of the First User;
a plurality of Approved User Identifiers to whom the said First User grants read consent to his personal and private sensitive data;
the time till which the read consent has been granted by the First User; and
storing the Approved User Identifiers along with the First User Identifier in its memory;

2. The method of claim 1, further comprising:
receiving, by one or more processors, at a computer Application, a request for a Authentication Token from a Second User, identified by a User Identifier such as email or National ID number;
authenticating the Second User based on a plurality of methods like username/password authentication, etc;
providing a JWT token to the Second User on successful authentication, comprising of:
a signed JWT token for the Second User; and
a plurality of User Identifiers that have granted read consent to the Second User

3. A computer-implemented method, comprising:
a Web Application that contains personal and private sensitive data of a User, identified by a Frist User Identifier;
receiving a Web Request via a URL, to access the personal and private data of the said First User by a Second User, the Web Request comprising of an Authentication token of the Second User, which comprises of a plurality of User identifiers that have granted the Second User read consent to their personal and private sensitive data;
determining that the said Second User is authorized to access personal and private data of the First User, by checking the presence of the First User Identifier in the list of Approved User Identifiers in the received JWT token of the Web Request from the Second User;
in the event the First User Identifier does not exists in the JWT token of the Second User, denying authorization for the application to access the web services, and rejecting the URL request;
in the event the First User Identifier exists in the JWT token of the Second User, approving the URL request for data access of the First User via the hosted web services;

4. The Authentication Token being issued by the Authorization Server comprising of the following information:

“Format”: “Format of the token - JWT”,
“Content”: “Actual token - JWT format”,
“isis”: “Auth Server of Enterprise XYZ”,
“subject”: “User Identifier”
“issueTime”: “Issued time in milliseconds”,
“expires”: “in Milliseconds from epoch”,
“readConsent”: [“User Identifier 1”, “User Identifier2 ”],
“readConsentTime”: “in Milliseconds from epoch”.
, Description:Technical Field
The present invention relates to providing consent to clients for access to personal and sensitive information via authorization tokens and an authorization server. The proposal allows the principal client to send its consents for read access to its personal and sensitive data to an authorization server listing out the identifiers of other clients to whom it grants read permissions, before these other clients actually request permission or are even aware of this data. This is different from current consent mechanisms, in that, the clients wishing to access personal and sensitive data of the principal client need to first request consent from the principal client, and only once the principal client approves this read request, other clients can access the data.

Background of the Invention

The present invention relates to consent management, and more particularly, it relates to a method for improving the conventional consent management process followed, wherein clients wishing to access sensitive and personal data of a principal client first need to request access permission, and only when the principal client approves the request, other clients can access this data. In the present invention, the principal client sends a list of client identifiers to an authentication/authorization server (henceforth called Auth server), which the authentication server maintains in its memory against the principal client’s entry. At a later point in time, when a client wishes to get a JWT or a similar authentication token from an Auth server, it authenticates to this authentication/authorization server, the Auth server checks its internal database to retrieve consents granted to this client by other clients. If the Auth server finds a match, then the Auth server can do either of the following things;
The auth server can include the list of identifiers, which could comprise of email identifiers, which might be the primary way of identification and authentication by the Auth server or an national identity card number or some other well know identity like a Social Security number that uniquely identifies this client. These list of email identifiers or other identifiers can be placed in the authentication token like a JWT token and sent back to the authenticating client, which now has a signed token from a trusted Auth server, granting it consent to read data of other clients mentioned in the Auth token.
The Auth server could also just include a URL instead of individual client identifiers, which could then be used by the client to retrieve a list of clients it hs read consent from.

In this way, the proposal provides a way for a client to apriority grant read consent to its data to other clients via a well-known client identifier. This will be very useful in some environments like healthcare, where a patient could grant read consent to its data to a wildcard domain like doctors@xyzhospital.com as an example, wherein the patient wishes to pre-grant read consent to all doctors. Later, when the doctors at “xyzhospital” need to discuss and diagnose the patient’s data, they already have read consent and do not need to acquire read consent from the patient, who might not even be available at that particular time to provide consent.

This is also a useful invention for for IoT devices, especially health-care IoT, which is closely related to personal life, as it deals with the sensitive personal information of the individual, and there needs to be a way to grant such read access to sensitive information.

The Auth server needs to be configured to track information, privileges, entitlements, assertions and other information associated with a plurality of users. These users are either clients granting read consent or other clients requesting authentication and a list of other clients who have granted read consent to these clients. This information may be incorporated in accordance with the present invention to facilitate authenticating users.

Brief Description of the Drawings
The foregoing summary, as well as the following detailed description of the invention, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, exemplary constructions of the invention are shown in the drawings. However, the invention is not limited to the specific methods and instrumentalities disclosed herein. In the following, the present invention will further be described by way of example only with reference to exemplary embodiments illustrated in the figures.

FIG. 1 is a schematic system drawing of a Clients connecting with “Authentication and Authorization” Server and an Application Server
FIG. 2 is a state diagram showing an example message flow of a client connecting to an “Authentication and Authorization” Server and receiving an Authentication token.
FIG. 3 is a schematic system drawing of a computer system that could be used for implementing an Application or “Authentication and Authorization” Server.

Summary of the Invention

This invention relates to providing consent to clients for access to personal and sensitive information via authorization tokens and an authorization server. The proposal allows the principal client to send its consents for read access to its personal and sensitive data to an authorization server listing out the identifiers of other clients to whom it grants read permissions

Detailed Description

In the following detailed description, for purposes of explanation and not limitation, specific details are set forth in order to provide a better understanding of the present disclosure. It will be apparent to one skilled in the art that the present disclosure may be practiced in other embodiments that depart from these specific details.

The architecture contemplated by the present invention may be based on the concept of a token. A token may be defined as a set of claims about a specific entity, signed by an issuing entity, the signature of which can be verified by a relying party (who has pre-established trust with the issuing entity). It may be assumed (by the relying party) that the issuing entity has performed adequate authentication of the specific entity before issuing the token to it.

Token={Set of Claims}+{Signature of the issuer}

The set of claims may be further defined to include the following information mandatorily

Set of Claims=Issuer, Issue Timestamp, Expiry Timestamp, Subject, Audience (optional)

In embodiments described below, permissions are contained in and conveyed by JSON web tokens (JWT tokens or JWTs). JSON is an open standard defined in RFC7519, RFC7515, RFC7516 and RFC7797. Of these standards, RFC7519 relates to creating JWT tokens. The JWT token is signed by the server's key to enable a client to verify its authenticity. The purpose of a JWT token is to allow secure communication between client and server. JWT tokens are access tokens created by a server for its clients which contain “claims” which are made by the client to the server, “claims” being the term used in RFC7519. The JWT tokens can be stored at the client in client-side storage. A JWT token is a type of client-accessible credential.

A JWT has three sections: header, payload and signature. The header and payload are Base64-encoded. The signature is created by feeding the header and payload through a signing algorithm together with a private key. The signature can be used to authenticate the JWT token by a verifying entity in possession of the private key.

A simplified form of a JWT token might be as follows:
{
"alg": "HS256",
"typ": "JWT"
} {
"sub": "1234567890",
"name": "Aseem Sethi",
"admin": true
} SIGNATURE

Some terminology used for describing implementations of the disclosure are as follows:

The Authentication Token being issued by the “Authentication and Authorization” Server comprising of the following information:
“Format”: “Format of the token - JWT”,
“Content”: “Actual token - JWT format”,
“isis”: “Auth Server of Enterprise XYZ”,
“subject”: “User Identifier”
“issueTime”: “Issued time in milliseconds”,
“expires”: “in Milliseconds from epoch”,
“readConsent”: [“User Identifier 1”, “User Identifier2 ”],
“readConsentTime”: “in Milliseconds from epoch”.

“Authentication and Authorization” Server: a software module that issues authentication tokens, JWT as an example, to users, such as clients. The authentication service may request end-user approval, userid/password combination, or OTP based authentication etc. The authorization server also has the role of revoking previously issued tokens that are in circulation. An Open Authorization (OAuth) server implementing Version 2.0 of Open Authentication specification is an example of an authorization server. OAuth is an open standard authorization framework which allows a third party to access a resource without the resource giving unencrypted credentials (e.g. username/password/client id) to the third party. OAuth is commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. OAuth provides a framework by which access tokens can be issued to clients by an authorization server with the approval of the resource owner. A client then uses the access token to access the protected resources hosted by a resource server.

“Format” is provided to allow a multitude of token formats—like SAML and JWT. In future, this invention can be used to include other types of tokens that are as yet unknown.

“Content” is the actual token.

“iss” Entity ID of the issuing App Admin. This entity ID is a globally unique identifier. “iss” MUST be in a valid URI format.

“subject” is the Client Identifier. This is the unique identifier given to this application or a client user by this App Admin. This ID uniquely identifies the client user to which this token is issued. This is the unique identifier that is sent in the JWT claim as a client identifier. This can also be a Health Identifier (Health ID), an National ID Number, PAN card number etc. This would uniquely identify the user that has been granted the JWT token.
The authorization and authentication server that is providing JWT token would base it on this identity.

“issueTime” The time this token is created/issued, in UTC time zone. The value is the number of milliseconds from January 1, 1970 00:00:00 UTC.

“expires” The time this token expires, in UTC time zone. The value is the number of milliseconds from January 1, 1970 00:00:00 UTC.

“readConsent”: This is a list of Client Identifiers that the user in “subject” field of this Authorization Token is granting read access to.

“readConsentTime” The time this readConsent expires, in UTC time zone. The value is the number of milliseconds from January 1, 1970 00:00:00 UTC.

FIG. 1 is a schematic system drawing of a computer system in one embodiment. The computer system comprises an Web Application Server 103 and a plurality of clients 101, 102. By way of example we show two clients, but the number is arbitrary and may be anything from one to a large number of clients. The computer system also includes an “Authentication and Authorization” server 108 (henceforth called just the Auth Server) responsible for issuing authentication tokens, like a JWT Token, to clients.

In one embodiment, the following section describes how a Client 101 authenticates itself to the Auth Server and then uses a Web URL to an endpoint on the Auth Server, and provides a list of Clients that it is giving consent to read its personal and private data. For example. Client 101 could give Client 102 read access, by calling the API endpoint in the Authorization Server, and passing in the body of the message a list of Client Identifiers, say, Client 102, whereby, the Authorization Server 105, would then update its internal memory tables to indicate that Client 101 has granted consent to Client 102 to read its personal and private data. Note that using an API endpoint with a HTTP GET request is one way in which the Client 101 could update the Auth Server with its consent information, like granting read consent to Client 102. There could be other ways to achieve this, and the end result would be that the Auth Server would have the list of Clients that Client 101 gives its consent to.

In the following section, we describe how another Client sat Client 102 gets Authenticated and Authorized by the same Auth Server 105, and in return gets a JWT token, that has a list of Clients that have provided it read consent. In one embodiment, Client 102 authenticates and authorizes itself, when it tries to access a personal and private data of Client 101 at the Web Application via 106 to the Application Server 103. The Web Application Server 103 could redirect him to the Authorization Server 105, if the Web Application Server 103 finds that the HTTP URL request from Client 102 does not have a JWT token, which means that the Client 102 has not yet authenticated itself with the Auth Server 105. Once the Client 102 authenticates with the Auth Server 105, it will receive a JWT token if it is successfully authenticated.

The Authorization Server 105, when returning a JWT token to the Client 101, would lookup its internal tables in memory to pick up a list of Clients who had consented earlier to share their personal and private data with Client 101. The Authorization Server 105, would then put all these Client Identifiers who were granted read consent to Client 102. In one embodiment, if the previous section was executed, then the Authorization Server 105, would have got an update from Client 101, providing read consent to Client 102 as described in the last section. Thus, when making the JWT token for Client 102, the Authorization Server would put Client 101 in the “readConsent” filed of the JWT token and send this JWT token to Client 102. Thus, at the end of this step, the Client 102 has successfully authenticated itself and has also got a JWT token from the Authorization Server, which comprises of readConsent from Client 101, which will allow Client 102 to access personal and private data of Client 101.

At this point, in one embodiment, Client 102 can access an API endppint of the Web Application server 103, requesting reading of Client 101’s personal and private data. The Application Server at 103, will verify the signature, and if it is correct, and if the JWT token has in its readConsent parameter, the Client Identifier of Client 101, it will allow read access to Client 102, to read Client 101 data stored in its Application Server.

FIG. 2 is a state diagram showing an example message flow in a typical embodiment. The client 201, referred to in the following as the client, initiates an Authentication procedure with the “Authentication and Authorization” 202. It would then receive in 204 an Authentication token from the server 202. This authentication token would be cryptographically signed by the server 202 by its private key, and the other entities like the Client 201 can verify this signature since they would have the public key of the server 202 configured in their memory at configuration time.

The token parts can be compressed (e.g. gzip, or any other compression type to make the token fit into either of the above fields. If compression is used, the message broker 202 should be configured to understand compressed JWT and decompress it accordingly before parsing.

The server 202, is configured to validate the JWT based on its private key which could be configured on the message broker in an offline manner or in any other manner.

The server validates the JWT and decodes it to:
extract information about the client's unique device identifier; and
saves the client’s identifier and JWT token in memory.

FIG. 3 shows a structure of a computer system 300 and computer program that may be used to implement embodiments of the invention, wherein the computer system may be a network node, such as a client or a server, authorization server or message broker server referred above. The computer system 300 comprises a processor 301 to provide a processor resource coupled through one or more I/O controllers 303 to one or more hardware data storage devices 308 and one or more I/O devices 307, which can manage graphic object requests, and a display 306 on which the graphics objects can be displayed. The processor 301 may also be connected to one or more memory devices 308, 309 via a memory unit 302. At least one of the memory devices 308 provides a memory resource which stores computer program, which is a computer program that comprises computer-executable instructions. The data storage devices 308, 309 may also store the computer program. The computer program stored in the storage devices 308 is configured to be executed by processor 301 via the memory devices 302. The processor 301 executes the stored computer program.

A further embodiment of the invention is a computer program product defined in terms of a system and method. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out aspects of the present invention. The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.

Aspects of the present invention are described herein with reference to flowchart illustrations and block diagrams of methods, systems and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

It will be clear to one skilled in the art that many improvements and modifications can be made to the foregoing exemplary embodiment without departing from the scope of the present disclosure.