Univers V-Commerce Protocol · UVCP
Identity
A person tells their assistant to act for them in a store. This capability says how the store asks them to confirm it, what the assistant is allowed to do afterwards, and how the person ends it.
- Capability
com.univershq.vcommerce.identity- Version
2026-09-17- Schema
https://vcommerce.univershq.com/2026-09-17/schemas/identity.json- Builds on
- OAuth 2.1 with PKCE, RFC 8414, RFC 8707, RFC 9207, RFC 9728, RFC 7009
Why it exists
The standards already say how to hand a credential to a client. They say nothing about the part a shop cares about: what an assistant must declare about itself, what a person is shown before they agree, what the house records, and what a house may refuse. This capability is those four things, and nothing else. It replaces no standard and adds no ceremony to one.
How a store declares it
In its UCP profile at /.well-known/ucp:
"com.univershq.vcommerce.identity": [{
"version": "2026-09-17",
"spec": "https://vcommerce.univershq.com/2026-09-17/specification/identity",
"schema": "https://vcommerce.univershq.com/2026-09-17/schemas/identity.json",
"config": {
"authorization_server": "https://store.example",
"metadata": "https://store.example/.well-known/oauth-authorization-server"
}
}]The declaration carries no endpoints of its own. Every address an assistant uses is read from the store's authorization server metadata, which is where the standards already say to look, so there is only ever one answer to where a thing is.
What an assistant is
An https URL it can prove it controls. That is the whole of its identity, and it is the only thing any caller can actually prove.
The store does not retrieve it
A store implementing this capability never fetches the assistant's URL. Retrieving an address chosen by a stranger means making a request on that stranger's behalf from inside the shop's own network, and the only thing it buys is a friendlier name on a screen. A name is a claim either way.
So the assistant is known by its address, and everything that would otherwise have come from a fetched document is derived from that address instead.
Where it may be sent back to
A redirect must be https and on the same origin as the assistant's identifier. Not a prefix, not a subdomain, and no exception for local addresses: an exception is a return address somebody else can claim.
Claimed and proved are two fields
A store records what an assistant called itself and the origin it controls, and never merges them into one. A claim and a fact counted as one number is a number nobody can act on. Where a store shows both to a person, the origin leads.
What a person is shown
Before anything is granted, on the store's own address, signed in as themselves:
| Shown | Why |
|---|---|
| The origin that is asking | The only part that was proved, so it is the part that leads. |
| The name it chose, if any | Beside the origin, marked as a claim, never instead of it. |
| What it would be allowed to do | In the person's own words, one line each. A scope with no sentence is not shown and is not granted: nobody can agree to what nobody explained. |
| For how long | Stated as a period, and it ends whether or not anybody returns. |
| What it cannot do | Said plainly, because the absence of a power is invisible otherwise. |
There is no option to agree once and skip the screen afterwards. A permission is a thing somebody chose on a day, and an approval that happens without them is not one.
What may be permitted
| Scope | What it allows |
|---|---|
com.univershq.vcommerce.place:read | Read the store as that person sees it, including a room kept for them. |
com.univershq.vcommerce.basket:write | Put pieces aside for them, which they decide whether to buy. |
com.univershq.vcommerce.handback:write | Hand them back to the store to finish an order themselves. |
Completing a purchase is not among them. A store that permits an agent to buy does so under a separate capability and a limit the house sets, and it is not this one.
Rules every store keeps
The person is never taken from the request
Whoever is approving is established by the store's own sign-in, at the moment they approve. A request that names the person it is for is a request that could name somebody else.
Proof of the exchange, always
PKCE with S256 is required. The plain method is not accepted. A code is single use and lives for seconds, and a code presented twice ends the permission rather than failing the request: two exchanges mean one of them was not the assistant.
A permission ends when the person says so
Not at an expiry, and not at the end of a session. A person can see every assistant they have permitted and end any of them, and it takes effect on that assistant's next request. Revocation from the assistant's side does the same thing.
Every refusal is the same sentence
A credential that never existed, one that expired, one that was withdrawn and one that belongs to another assistant are all answered identically. A door that distinguishes them is answering questions for somebody working through possibilities.
A credential is not a cookie
A store refuses a request that carries a person's credential together with a browser origin. An assistant is not a web page, and a page that has one has no business presenting somebody else's permission.
A house may refuse an assistant
By origin, because the origin is the half that cannot be faked. A refused assistant is refused before a person is ever shown a screen for it, and every credential it already holds stops working.
Versions
A version is a date. A published version never changes: its schema and this page stay at their addresses. Capabilities version independently of one another, so this one carries its own date and says nothing about any other.