Brainstorming: Accessibility-First Interaction Negotiation for Decentralized Identity

Hi CCG folks,

I wanted to open a discussion around an accessibility problem in
decentralized identity that recently changed how I think about inclusivity,
privacy, and some of the assumptions built into holder–verifier interaction
flows.

Recently, while visiting an institution supporting specially abled
individuals, I had conversations with two people about decentralized
identity systems and Verifiable Credentials. One person was blind, and
another had no arms. During the discussion, one question came up that
stayed with me:

“Would this infrastructure actually work for us, or is it built around
assumptions we cannot satisfy?”

I found that question difficult to answer honestly.

When we look at many holder interaction flows today, they often assume some
combination of visual, manual, or device-centric interaction. For example:

   1. Scanning a QR code.
   2. Navigating a wallet interface visually.
   3. Responding to a push notification.
   4. Performing a touch-based biometric action.
   5. Manually approving a presentation request.

For a blind person, the visual layer may be the problem. For a person
without arms, the manual interaction layer may be the problem. More
importantly, these are different constraints and require different
interaction models.

My first instinct was to think in terms of specialized wallets,
accessibility-specific credential profiles, or some type of
accessibility-oriented identity abstraction. But the more I thought about
it, the more that direction felt wrong at the architectural level.

It seems to create at least two problems:

   1. Privacy and unnecessary disclosure
   Accessibility requirements should not require disclosure of sensitive
   personal or medical characteristics to a verifier. If accessibility becomes
   something cryptographically signaled or embedded in identity
   infrastructure, we risk creating new correlation and tracking surfaces.
   2. Interoperability and fragmentation
   Disability is not one category. A model that works for one person may
   not work for another. A single “accessibility profile” or identity
   abstraction feels unlikely to generalize cleanly and may fragment
   implementations.

That led me to think about the problem differently:

*What if accessibility in decentralized identity is better understood as an
interaction negotiation problem rather than an identity attribute problem?*

In that framing, DIDs, Verifiable Credentials, and proofs remain entirely
standard and unchanged. At the credential layer, holders remain
indistinguishable from one another. The difference moves to the interaction
layer.

Instead of signaling identity traits, systems could negotiate interaction
constraints or interaction capabilities.

Very roughly, that could look something like this:

   1. Credentials, proofs, and DID infrastructure remain
   accessibility-agnostic.
   2. Interaction requirements are expressed abstractly rather than
   personally. For example:
      - visual interaction unavailable
      - manual interaction unavailable
      - audio-mediated interaction preferred

   The verifier learns *how* interaction should happen, not *why*.
   3. Negotiation happens during early protocol establishment, potentially
   through wallet metadata, DIDComm discovery, OID4VP-related mechanisms, or
   presentation workflows.
   4. A trusted local assistive layer (for example, an accessibility-aware
   wallet interface or mediation agent) translates interaction requests into a
   usable experience while preserving user intent and cryptographic integrity.
   5. Credential presentation and verification remain standard and
   interoperable.

In such a model, a verifier would not need to know whether someone is
blind, has limited mobility, or uses a particular assistive setup. The
verifier would only know how interaction can successfully happen.

There also seem to be some useful places to look for prior work or
alignment:

   1. OID4VP and wallet metadata already negotiate technical capabilities
   and may offer a place to think about interaction capability negotiation.
   2. DIDComm discovery seems conceptually relevant because it already
   deals with feature discovery between parties.
   3. Accessibility work such as WAI-ARIA and adaptive accessibility
   approaches like ISO/IEC 24751 (AccessForAll) may provide useful conceptual
   grounding around describing interaction requirements without disclosing
   underlying conditions.
   4. Multi-modal authentication work in adjacent ecosystems may also have
   useful lessons here.

At the same time, there are a few obvious design challenges that would need
careful thinking:

   1. Privacy leakage through uniqueness
   Even abstract interaction capabilities can become fingerprinting vectors
   if they are too detailed or overly specific. Any vocabulary would likely
   need to remain intentionally coarse-grained.
   2. Capability deadlocks
   What happens when a verifier environment only supports one interaction
   pattern (for example, a kiosk with only a screen and camera)? Some form of
   mediation or delegation may be necessary while still preserving
   interoperability.
   3. Intent and trust boundaries
   If interaction becomes mediated through assistive systems, preserving
   holder intent becomes important. Accessible interaction should not weaken
   user agency or make it easier to trick a user into authorizing something
   unintentionally.

A few questions I wanted to ask the group:

   1. Has interaction negotiation for accessibility already been explored
   in DIDComm, wallet metadata, OID4VP, Presentation Exchange, or related
   efforts?
   2. Would a lightweight interaction capability vocabulary make sense as
   an interoperability layer?
   3. How could something like this integrate cleanly into existing
   verifier assumptions without introducing privacy or fingerprinting concerns?
   4. Are there adjacent accessibility efforts we should align with rather
   than reinvent?

My current thinking is to first write a short problem statement and
requirements document before getting into protocol mechanics, mainly to
understand whether there is a real interoperability gap worth addressing
here.

Would genuinely appreciate thoughts, critiques, references, or
collaboration from anyone thinking about accessibility, wallet UX,
privacy-preserving interaction, or decentralized identity architecture.

Best regards,
Amir Hameed Mir