Relationship to established identity systems

This comparison locates design choices; it does not confer compliance.

10.1 OAuth 2.0 and PKCE

OAuth 2.0 is an authorization framework for limited access to protected resources. PKCE, defined by RFC 7636, adds a per-request verifier and derived challenge to mitigate authorization-code interception for public clients. The current handoff adopts the verifier/challenge pattern and state-bound redirect journey. It does not implement the complete OAuth role, endpoint, metadata, token, scope, error, and security profile. It should therefore be described as PKCE-bound, not “OAuth-compliant.”

10.2 OpenID Connect

OpenID Connect is an identity layer over OAuth 2.0. It lets a relying party verify authentication performed by an OpenID Provider and receive end-user claims, principally through an ID Token and standardized endpoints. Sign in with Wellbeing Identity currently issues no OpenID Connect ID Token and exposes no claimed OIDC discovery or certification. Its concept of identity is also wider than the claims ordinarily required for authentication, which is why the current handoff deliberately transmits less than the private identity contains.

OIDC remains an important interoperability path. A future profile could map the bounded identity reference to a stable or pairwise subject identifier, express purpose through scopes or authorization details, and keep identity projections outside the default sign-in response. That work would require a new specification, threat analysis, client registration model, key management, and conformance testing.

10.3 Passkeys and WebAuthn

WebAuthn defines public-key credentials scoped to a relying party and mediated by the user agent and authenticator. Passkeys can improve phishing resistance and remove dependence on emailed links. They answer how a person strongly authenticates to a service; they do not by themselves define the eight-node identity model, owner-controlled projections, or cross-application authority boundaries.

Word Wallet could adopt WebAuthn as an identity-side authentication method without changing the central purpose-bound handoff thesis. The relying application would still need to know which bounded relationship it may create and what must not be disclosed.

10.4 Decentralized Identifiers

W3C DID Core defines a URI scheme and data model for identifiers associated with DID documents and verification methods. The current did:iov:member:<uuid> is described by the IoV Spec as a Phase implementation anchor. This paper does not claim that did:iov is registered, globally resolvable, decentralized, or conformant with every DID Core method requirement. Its present value is a nonsemantic, stable internal identity reference.

That limitation is constructive. The continuity architecture can be reviewed independently of claims about decentralization. Future method work would need resolution, governance, cryptographic control, recovery, rotation, privacy, and interoperability definitions.

10.5 Verifiable Credentials and wallet presentation

W3C Verifiable Credentials Data Model 2.0 defines an issuer-holder-verifier model for tamper-evident claims. OpenID for Verifiable Presentations 1.0 defines a protocol for requesting and presenting credentials over OAuth-derived rails. ~WellbeingIdentity includes credential and attestation contexts, but the current Value Log and ~Cortisol Checker~ sign-ins do not require a verifiable presentation and do not present a credential bundle to the relying application.

This separation is useful. Authentication continuity, credential presentation, private identity projection, and public disclosure are related capabilities, not synonyms. A future application that genuinely needs a credential should declare the requested claim, issuer trust, presentation purpose, retention, verifier policy, and failure behavior. It should not receive all available identity material because the wallet can technically present it.

10.6 Comparative summary