IP Library Granted Patent US 12676750
Granted Patent B2
US 12676750 · App. 17/585,522 · Granted Jul 7, 2026

Methods, systems, and devices for server control of client authorization proof of possession

Inventors: Itai Ephraim Zilbershtein (Hod Hasharon, IL); Moshe Elad (Gedera, IL); Ezra Darshan (Beit Shemesh, IL); David Livshits (Geva Binyamin, IL); Michael Joseph Burns (Jerusalem, IL); Assaf Yosef Tamir (Jerusalem, IL)
Assignee: Synamedia Limited
H04L9/3242H04L9/0891H04L9/3213H04L9/3247H04L63/0442H04L63/0807H04L63/0876
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12676750
App. No.
17/585,522
Granted
Jul 7, 2026
Kind
B2
Abstract

Techniques for server control of client authorization proof of possession are described herein. In various embodiments, a first server provisions client authorization proof of possession for a client device a real-world time, a client public key, and a client private key. The first server generates provisioning response message(s) including the client public key, the client private key, the real-world time, and/or an assertion object, and sends the message(s) to the client device. In various embodiments, a client device obtains an authorization proof token generated based on a client public key, a client private key, and a real-world time provisioned by a first server. The client device generates a request and sends the request to a second server, the request includes the authorization proof token and an assertion object from the first server signed by a server private key and an expiration time and a reference to the client public key.

Claims (72)

1 . A method comprising:

at a first server including one or more processors and a non-transitory memory:

obtaining, via a second server that is distinct from the first server, a provisioning request for a client device upon the second server successfully authenticating the client device;

in response to obtaining the provisioning request, provisioning, by the first server for the client device a real-world time, and generating, by the first server for the client device a first client public key and a first client private key;

generating one or more provisioning response messages that include the first client public key, the first client private key, the real-world time, and a first assertion object, wherein the first assertion object includes a reference to the first client public key and an expiration time;

sending the one or more provisioning response messages to the client device; and

facilitating validation of the first assertion object by the second server and facilitating provisioning refresh of the first assertion object when the expiration time is within a threshold limit from the real-world time.

2 . The method of claim 1 , wherein the provisioning request includes an initial provisioning token for the client device, and the method further includes:

receiving, via the second server, a request for the initial provisioning token from the client device, wherein the request includes a unique identifier associated with the client device;

generating the initial provisioning token in response to receiving the request, including binding data to be included in the first assertion object to the unique identifier; and

sending, via the second server, the initial provisioning token to the client device.

3 . The method of claim 2 , wherein:

a code is generated by the second server, bound to the unique identifier, and provided to the client device by the second server upon successful authentication of the client device by the second server;

the code is provided by the client device to the second server along with the request for the initial provisioning token; and

the request for the initial provisioning token is forwarded by the second server to the first server upon a successful validation of the code from the client device by the second server.

4 . The method of claim 1 , wherein:

the first assertion object is signed with a first key; and

facilitating validation of the first assertion object by the second server includes sharing the first key with the second server to validate the first assertion object.

5 . The method of claim 1 , wherein facilitating validation of the first assertion object by the second server includes:

receiving a validation request from the second server, wherein the validation request includes the first assertion object; and

sending to the second server a validation indicator upon validating the first assertion object.

6 . The method of claim 1 , wherein:

the first server and the second server are distinct from a third server for providing resources to the client device; and

the second server receives an authorization request for access to the third server including an application access token and parameters associated with the third server; validates the authorization request; and upon validating the authorization request, generates a resource server access token for access to the third server based on the parameters and sends the resource server access token to the client device, wherein the authorization request includes the first assertion object.

7 . The method of claim 1 , further comprising:

provisioning a symmetric signing key unique for the client device, wherein the client device uses the symmetric signing key to sign an authorization proof token, and the signed authorization proof token is verifiable by a third server.

8 . The method of claim 7 , further comprising:

synchronizing a secret between the first server and the second server, wherein the second server shares the secret with the third server,

wherein provisioning the symmetric signing key unique for the client device includes:

generating a wrap for the symmetric signing key by encrypting the symmetric signing key with the secret, and

sending the symmetric signing key, the wrap, and a key identifier associated with the secret to the client device.

9 . The method of claim 7 , further comprising:

synchronizing a seed between the first server and the second server, wherein the second server shares the seed with the third server,

wherein provisioning the symmetric signing key unique for the client device includes:

deriving the symmetric signing key from the seed, and

sending the symmetric signing key and a key identifier associated with the seed to the client device.

10 . The method of claim 7 , wherein provisioning the symmetric signing key unique for the client device includes causing the third server to store the symmetric signing key and a client identifier associated with the symmetric signing key in a data store.

11 . The method of claim 7 , further comprising:

creating a replacement shared secret periodically to replace a shared secret for provisioning the symmetric signing key, wherein the replacement shared secret is shared between the first server and the second server distinct from the first server, and deployed to the third server, distinct from the first server and the second server; and

retaining the shared secret on the third server for a period of time for requests from the client device signed with the symmetric signing key provisioned based on the shared secret before retiring the shared secret.

12 . The method of claim 1 , further comprising:

receiving a provisioning refresh request from the client device, wherein the provisioning refresh request includes the first assertion object;

in response to receiving the provisioning refresh request, provisioning a second client public key and provisioning a second client private key;

generating a second provisioning response message that includes the second client public key, the second client private key, and a second assertion object, wherein the second assertion object is generated based on the first assertion object and includes a second reference to the second client public key and a second expiration time; and

sending the second provisioning response message to the client device.

13 . The method of claim 12 , wherein the first assertion object is signed with a first signature corresponding to a server private key of the first server and signed with a second signature corresponding to the first client private key, the first client public key is attached to the first assertion object, and the method further includes validating the first assertion object in response to receiving the provisioning refresh request, including:

validating the first signature using a server public key of the first server;

validating the second signature using the first client public key attached to the first assertion object; and

matching the first client public key attached to the first assertion object with the first client public key or a hash of the first client public key included in the first assertion object.

14 . The method of claim 13 , wherein validating the first assertion object in response to receiving the provisioning refresh request includes:

incrementing a count of provisioning refresh requests from the client device; and

determining whether the number of provisioning refresh requests from the client device has exceeded a threshold over a period of time.

15 . The method of claim 1 , wherein sending the one or more provisioning response messages to the client device includes:

protecting the one or more provisioning response messages by performing one or more cryptographic operations on the one or more provisioning response messages prior to sending the one or more provisioning response messages, wherein the protected one or more provisioning response messages are verifiable by the client device.

16 . The method of claim 1 , further comprising:

generating a protected message with configuration changes including a server notion of real-world time; and

sending the protected message with the configuration changes to the client device and causing the client device to apply the configuration changes, including causing the client device to align a client notion of real-world time with the server notion of real-world time.

17 . The method of claim 16 , wherein the protected message with the configuration changes includes a periodic refresh interval for the client device to generate a heartbeat request.

18 . A first server comprising:

one or more processors; and

a non-transitory memory storing computer readable instructions, which when executed by the one or more processors, cause the first server to:

obtain, via a second server that is distinct from the first server, a provisioning request for a client device upon the second server successfully authenticating the client device;

in response to obtaining the provisioning request, provision, by the first server for the client device a real-world time, and generate, by the first server for the client device a first client public key and a first client private key;

generate one or more provisioning response messages that include the first client public key, the first client private key, the real-world time, and a first assertion object, wherein the first assertion object includes a reference to the first client public key and an expiration time;

send the one or more provisioning response messages to the client device; and

facilitate validation of the first assertion object by the second server and facilitate provisioning refresh of the first assertion object when the expiration time is within a threshold limit from the real-world time.

19 . A non-transitory computer-readable medium that includes computer-readable instructions stored thereon that are executed by one or more processors of a first server to perform operations comprising:

obtaining, via a second server that is distinct from the first server, a provisioning request for a client device upon the second server successfully authenticating the client device;

in response to obtaining the provisioning request, provisioning, by the first server for the client device a real-world time, and generating, by the first server for the client device a first client public key and a first client private key;

generating one or more provisioning response messages that include the first client public key, the first client private key, the real-world time, and a first assertion object, wherein the first assertion object includes a reference to the first client public key and an expiration time;

sending the one or more provisioning response messages to the client device; and

facilitating validation of the first assertion object by the second server and facilitating provisioning refresh of the first assertion object when the expiration time is within a threshold limit from the real-world time.