Skip to content
Draft
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -3765,6 +3765,25 @@ <h5>Update Status</h5>
list credential accordingly.
</p>

<p>
Comment thread
PatStLouis marked this conversation as resolved.
Status mechanisms associate each [=verifiable credential=] with a
<code>statusListIndex</code> in a list (see, for example, [[VC-BITSTRING-STATUS-LIST]]).
Comment thread
PatStLouis marked this conversation as resolved.
Outdated
Implementations that assign those indices usually track which values are in use so
indices are not reused incorrectly and status updates modify the correct entry. When a
status service supports more than one such tracker鈥攕uch as separate allocators per
tenant, deployment, or <code>statusPurpose</code>鈥攖he optional <code>indexAllocator</code>
request field names which allocator context applies to this update. The same identifier
would typically have been fixed or returned when the index was originally assigned at
issuance (or when the list was provisioned), so issuance and status-update flows stay
consistent even though list creation and credential issuance are separate API surfaces
in this specification.
</p>

<p class="note" title="indexAllocator values">
Permitted <code>indexAllocator</code> strings are implementation-defined; this
specification does not mandate particular values or a discovery mechanism for them.
</p>

<div class="api-detail"
data-api-endpoint="post /credentials/status"></div>
</section>
Expand Down
21 changes: 18 additions & 3 deletions oas.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -804,7 +804,10 @@ components:
type: object
required: ['credentialId', 'credentialStatus', 'status']
additionalProperties: false
description: Credential status information to be updated.
description: >-
Credential status information to be updated. When a deployment runs more than one
mechanism that assigns or records `statusListIndex` values, an optional
`indexAllocator` can identify which allocator context to use (see that property).
properties:
credentialId:
type: string
Expand All @@ -830,12 +833,24 @@ components:
description: Specifies the new status.
indexAllocator:
type: string
description: For services to use which indexes are being used/assigned to VCs.
description: >-
Optional identifier for the index-allocation context the status service should
use for this request. Status mechanisms such as bitstring status lists associate
each credential with a `statusListIndex` inside a list; implementations often keep
internal bookkeeping (free lists, counters, per-tenant pools, etc.) so indices are
not double-assigned and updates target the correct row. When multiple allocators
exist鈥攆or example, separate pipelines per tenant, environment, or
`statusPurpose`鈥擿indexAllocator` tells the service which registry or policy to
Comment thread
PatStLouis marked this conversation as resolved.
Outdated
consult or update alongside `credentialId` and `credentialStatus`. Omission is
allowed when the implementation infers a single default allocator or when
`credentialStatus` already fully identifies the list entry. Allowed values are
implementation-specific; this specification does not define a registry of names.
example:
{
"credentialId": "0fc754bc-fc32-46a0-aec1-a5ef385e7ea0",
"credentialStatus": { "type": "BitstringStatusList", "statusPurpose": "revocation" },
"status": True
"status": true,
"indexAllocator": "tenant-acme-revocation"
}
CreateStatusListRequest:
type: object
Expand Down
Loading