How a Service Verifies an NFT-backed Request

There is an NFT in the wallet, so the application grants access. That makes a short demo. A working service needs to answer the question the demo leaves out: why is this particular request allowed to execute?

An NFT can represent access to storage or the right to use a service. The resource service has to turn that representation into a concrete decision. Can this person upload a file to this space, right now? Can they change this domain's configuration? A successful presentation brings the evidence into the system. The decision still has to follow.

ArcBlock's DID Wallet and DID Connect documentation gives us a useful place to start. Following that interaction into the service explains how an NFT connects to a resource. Much of the engineering happens after the user slides to confirm.

What the wallet presents

The DID Wallet guide to presenting an NFT or Passport describes a simple interaction. An application requests an NFT. The wallet shows eligible items, and the user selects one and confirms. The guide makes a point of saying that the NFT is not sent to the application.

Here, sending means transferring the asset. The application still receives information it can verify. That distinction matters to the person confirming the request: demonstrating a qualification does not mean handing over the asset that represents it.

The DID Connect Request NFT example shows the application side. A request can specify acceptable object types and trusted issuers. Its response handler includes proof checks and a subsequent call for asset verification. Selecting something in the wallet and accepting it on the server are separate steps.

This is the division of work behind ArcBlock's resource model. The wallet helps the user present evidence. DID provides the identity foundation, and a Verifiable Credential expresses a claim about rights. The resource service considers that evidence alongside current asset state and the operation being requested.

A proof has to belong to this request

Receiving an NFT identifier proves very little. Someone can copy the identifier. A credential file can be copied too. The service needs evidence that the responding party can provide the required proof of control.

DIDs provide a foundation for identifying the requester and verifying associated keys. Authentication has a distinct purpose within a DID document; a verifier needs to use verification methods according to the applicable DID method and protocol.^[1] For an individual interaction, the proof should also be bound to the request and its intended application, with protection against replay. Otherwise, an intercepted response may be usable again.

The public DID Connect example checks the proof's time and verifies a signed message that includes the application's address. That connects the proof to a target application and a time. A complete request protocol also has to handle the lifetime of challenges and replay protection.

There is another distinction worth making explicit. A credential's subject is the entity described by its claims. Its holder possesses and presents it. The current owner of an NFT is recorded by the relevant asset system. Those roles can overlap, but they need not be the same.^[2] A credential might describe a storage resource while a user presents it. The service needs to establish the user's authority over that resource, without treating the user and the resource as one identity.

Proving who sent the request leaves the next question open: what does that party have permission to do?

Who issued the right, and what does it cover?

A valid signature establishes the result of a cryptographic check. The service still has to decide whether it accepts that issuer's claims about this kind of resource.

An application cannot make someone an administrator simply because they present a self-issued administrator credential. There must be a reason to accept the issuer's authority. The trustedIssuers condition in the DID Connect request is an entry point for expressing that expectation. Filtering the wallet's choices helps users select relevant evidence. The service must still verify what it actually receives.

Then it has to interpret the right.

Consider an NFT representing permission to use a particular storage space. Reading from that space does not necessarily include deleting its files. Using it need not include changing its billing settings or handing over administrative control. The service must match the resource and permitted operation to the request in front of it. That is what scope means in practice: a right described precisely enough to decide an action.

“Has an NFT” is a coarse condition. An accepted issuer's valid claim, covering this resource and this operation, is evidence a service can use in an authorization decision.

The W3C Verifiable Credentials data model explicitly addresses the need to combine credentials with an authorization framework.^[3] The verifiable claim supplies evidence; the service's rules determine its effect. A credential format cannot decide on behalf of every service what holding an object should permit.

The figure lists the checks a decision depends on; a protocol may combine or reorder them.

A relationship can change after issuance

A signed claim can last a long time. The relationship it describes may change. If a service promises access to the current NFT holder, it needs a sufficiently fresh view of ownership.

Someone who held an NFT yesterday may have transferred it today. A cached verification result needs to be reconsidered according to the service's rules. Whether an asset has been consumed, or a credential remains within its validity period, can matter too. Where a credential uses a status mechanism, the verifier also needs to process states such as suspension or revocation according to that mechanism. These are distinct from whether a signature verifies.^[4]

Transfer introduces a practical question. The previous user may already be logged in, with a session that has not expired. What happens to that session after ownership changes?

A service design needs an answer. Possible approaches include shorter session lifetimes, checking again before sensitive operations, or invalidating existing authorization when relevant state changes. The appropriate choice depends on the service's promise and the delay it can accept. The meaning of transfer, for that service, includes this behavior.

Delegation needs the same precision. If an asset protocol supports an operator or transfer approval, permission to transfer the NFT should not automatically become permission to read the resource's files. The resource service must define which delegations it accepts and how it verifies them.

This example concerns a transferable right. Existing sessions follow the service’s own rules.

The decision must reach the operation

Put these questions into a hypothetical file upload, and the remaining work becomes tangible. The service has established the requester, accepted the issuer, and checked that the current right permits writing to the target space. It still needs to determine whether space is available.

Quota changes during use. Two uploads arriving together may both observe the same remaining capacity. The service needs to coordinate checking and reserving capacity so that the same allowance cannot be spent twice. A single-use entitlement raises a related problem: repeated requests and retries after failures must not accidentally consume the entitlement more than intended. These are responsibilities of the resource service as it executes the right.

The user does not need to see that machinery at every interaction. It does need to exist. A login screen that reports successful verification does not protect a file endpoint that accepts whatever resource identifier the browser sends. The interface controlling the resource must enforce the rules, or validate a scoped authorization result that is still valid.

Unavailability also needs defined behavior. If a state service cannot be reached, an application might pause new operations or accept previously verified state within a defined window. Each choice has a cost. The immediacy promised to users should match the behavior the service can deliver.

One confirmation should lead to an explainable decision

To see the model in practice, read the DID Wallet presentation guide alongside the DID Connect request example. One explains what the user chooses. The other shows how the evidence enters the application. The resource service completes that interaction with the authorization rules and state handling required for its operations.

I find this a useful test for any NFT resource design: pick a real operation and explain why it is allowed, including the conditions under which it would be refused.

Someone uploading a file should not have to learn a credential model first. The application, however, needs to know who has which right over which resource, and whether that right still applies. Enforcing that decision in the service is what connects the NFT in the wallet to a usable resource.

References