AI Summary of “OpenID for Verifiable Credential Issuance – draft 13” by Otio.AI

Introduction

  • Defines an OAuth protected API for issuing Verifiable Credentials.
  • Credentials can be of various formats, including SD-JWT VC, mDL, and VCDM.
  • Verifiable Credentials are similar to identity assertions and can be securely presented without the Credential Issuer’s involvement.
  • Access to the API is authorized using OAuth 2.0.

Terminology

  • Credential: A set of claims about a subject made by a Credential Issuer.
  • Verifiable Credential (VC): An Issuer-signed Credential whose integrity can be cryptographically verified.
  • Credential Issuer: An entity that issues Verifiable Credentials, acting as an OAuth 2.0 Authorization Server.
  • Holder: An entity that receives and controls Verifiable Credentials.
  • Verifier: An entity that requests, receives, and validates Verifiable Presentations.
  • Issuer-Holder-Verifier Model: A model for exchanging claims via Verifiable Credentials.
  • Holder Binding: Ability of the Holder to prove legitimate possession of a Verifiable Credential.

Overview

  • Credential Issuer: Defines an API for Credential issuance with endpoints for Credential, Batch Credential, Deferred Credential, and Credential Offer.
  • OAuth 2.0: Utilizes OAuth 2.0 Authorization Server to authorize access, supporting various OAuth 2.0 Grant Types.
  • Core Concepts: Wallet sends Credential Requests to the Credential Endpoint, supporting multiple Credential formats and types.
  • Authorization Code Flow: Uses the authorization_code grant type to issue Access Tokens, with variations for Wallet-initiated and Issuer-initiated flows.
  • Pre-Authorized Code Flow: Uses a Pre-Authorized Code for Credential issuance, bypassing the Authorization Endpoint.

Credential Offer Endpoint

  • Used by a Credential Issuer to initiate Credential issuance.
  • Credential Offer can be sent by value or reference.
  • Parameters include credential_issuer, credential_configuration_ids, and optional grants.

Authorization Endpoint

  • Used to request access to the Credential Endpoint.
  • Supports authorization_details and scope parameters to request specific Credential types.
  • Additional parameters include wallet_issuer, user_hint, and issuer_state.
  • Pushed Authorization Requests are recommended for security.

Token Endpoint

  • Issues Access Tokens and optionally Refresh Tokens in exchange for Authorization Codes.
  • Supports Pre-Authorized Code Flow with parameters pre-authorized_code and tx_code.
  • Successful Token Responses may include c_nonce and c_nonce_expires_in.

Credential Endpoint

  • Issues Credentials upon presentation of a valid Access Token.
  • Supports cryptographic binding of Credentials to the End-User’s identifier.
  • Credential Requests include parameters like format, proof, and optional credential_response_encryption.

Batch Credential Endpoint

  • Issues multiple Credentials in one response.
  • Batch Credential Requests contain multiple Credential Request objects.
  • Batch Credential Responses include an array of Credential Response objects.

Deferred Credential Endpoint

  • Used for issuing Credentials that require additional processing time.
  • Deferred Credential Requests include a transaction_id.
  • Deferred Credential Responses follow the same format as immediate Credential Responses.

Notification Endpoint

  • Used by the Wallet to notify the Credential Issuer of events related to issued Credentials.
  • Notification Requests include notification_id and event.
  • Successful Notification Responses return HTTP status code 204.

Security Considerations

  • Trust between Wallet and Issuer is crucial, with mechanisms like key attestation, app attestation, and device attestation.
  • Credential Offers must be treated as untrusted until verified.
  • Pre-Authorized Code Flow requires measures to prevent replay attacks and phishing.
  • Credential lifecycle management and proof replay prevention are essential for security.
  • TLS requirements and protecting Access Tokens are critical for secure implementation.

Implementation Considerations

  • Claims-based and non-cryptographic binding of Credentials are supported.
  • Multiple accesses to the Credential Endpoint are allowed, with policies for refreshing issued Credentials.
  • Privacy considerations include user consent, minimum disclosure, and secure storage of Credentials.
  • Correlation prevention and identifying the Credential Issuer and Wallet are important for privacy.

Credential Format Profiles

  • Defines profiles for W3C Verifiable Credentials, ISO mDL, and IETF SD-JWT VC.
  • Each profile includes format identifiers, authorization details, Credential Requests, and Credential Responses.