How Drawspan works
Drawspan issues signed, time-limited licence leases that your application verifies locally. Customers can keep working through a temporary outage, but offline access still ends at the lease's signed expiry time.
Drawspan decides whether access should be issued. Your application checks the signed result and renews it when a connection is available.
A licence decision, from issue to renewal
The SDK does not call Drawspan before every protected action. It works with a signed lease that has a clear start and end.
- 1
Drawspan issues a signed lease
The lease records who and what it covers, the licence policy and the exact time it expires.
- 2
The SDK verifies it locally
Your integration contains the vendor's public key. The private signing key is never distributed with the application.
- 3
The application uses the verified lease
A valid cached lease can keep working when Drawspan cannot be reached, but only until its signed expiry time.
- 4
The SDK renews in the background
Renewal updates the local proof of access. If connection attempts keep failing, access ends when the existing lease expires.
How the lease stays trustworthy
Each vendor has its own signing key. Drawspan signs a canonical lease payload using ECDSA P-256 with SHA-256, and the SDK checks that signature before trusting the lease.
Changed lease data is rejected
Changing a signed field breaks the signature. The SDK also rejects malformed leases, unknown key identifiers, leases issued too far in the future and expired leases.
Verification happens before a network request
The SDK reads and verifies the cached lease locally. A connection can renew that proof, but is not needed to interpret one the application already holds.
A valid signature establishes the integrity and origin of the lease data. It does not make the plugin itself tamper-proof or replace the vendor's own application-security work.
What happens when Drawspan cannot be reached
A temporary network or service outage does not erase access that has already been issued. The lease remains subject to its original limits.
Offline use still has a fixed end
Renewal retries after connection failures. If it remains unavailable, the cached lease expires as issued. Offline use is never indefinite.
Moving the clock back cannot extend a lease
The SDK keeps a local high-water mark for time it has already seen. Clock rollback is checked against a small tolerance. A larger rollback blocks cached access until an online renewal confirms time again.
Local credentials are not stored as readable text
The member credential is protected with Windows DPAPI for the current user. This protects data at rest; it does not make a compromised Windows session safe.
No constant connection is required
The SDK contacts Drawspan for licensing work such as renewal. It does not send a separate presence heartbeat, and recent contact is not presented as proof that an application is running now.
Other service boundaries
Lease verification protects the decision inside the application. Drawspan also keeps customer access separate from vendor administration and keeps email delivery outside the business request that queued it.
One session does not cross into another portal
Vendor and customer access stay separate. Vendor-console and organisation-portal sessions use different subjects and authorization policies, so a session from one side does not satisfy the other side's policy.
Email delivery does not decide whether an action succeeded
Signups and invitations queue email in the same database transaction as the change that caused it. Delivery happens after commit and is retried. A mail-relay failure does not turn a committed business action into a failed request.