Skip to main content

VESPER - VErifiable STI Personas
draft-wendt-stir-vesper-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Chris Wendt , Robert Śliwa
Last updated 2024-06-25
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wendt-stir-vesper-00
Secure Telephone Identity Revisited                             C. Wendt
Internet-Draft                                                  R. Sliwa
Intended status: Informational                               Somos, Inc.
Expires: 27 December 2024                                   25 June 2024

                    VESPER - VErifiable STI Personas
                       draft-wendt-stir-vesper-00

Abstract

   This document extends the STIR architecture by specifying the use of
   JSON Web Tokens (JWT) and Selective Disclosure JWT (SD-JWT) for
   representing persona related information intended to be the output of
   a Know Your Customer (KYC) or Know Your Business (KYB) type of
   vetting process.  It defines entities called Vetting Agents (VA) that
   perform a vetting of persona related information and can issue a
   verifiable token bearing the VA signature, containing information
   that can be disclosed or selectively disclosed to an interested
   party.  The Vetted Entity (VE) can hold this token in selectively
   disclosable forms to disclose specific information to the third
   parties.  The vesper token enables the delivery and verification of
   information with privacy protecting mechanism in a complete,
   selective or zero knowledge manner specifically supported by the SD-
   JWT.  This document also describes an API standard to be supported/
   hosted by a Vetting Agent (VA), which allow vetted parties to present
   tokens proving their KYC/KYB conformance, and incorporates proof of
   possession to ensure the legitimacy of the entity presenting the
   token.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://appliedbits.github.io/draft-wendt-stir-vesper/draft-wendt-
   stir-vesper.html.  Status information for this document may be found
   at https://datatracker.ietf.org/doc/draft-wendt-stir-vesper/.

   Discussion of this document takes place on the Secure Telephone
   Identity Revisited Working Group mailing list (mailto:stir@ietf.org),
   which is archived at https://mailarchive.ietf.org/arch/browse/stir/.
   Subscribe at https://www.ietf.org/mailman/listinfo/stir/.

   Source for this draft and an issue tracker can be found at
   https://github.com/appliedbits/draft-wendt-stir-vesper.

Wendt & Sliwa           Expires 27 December 2024                [Page 1]
Internet-Draft                   vesper                        June 2024

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 27 December 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Vetting Process Overview  . . . . . . . . . . . . . . . . . .   5
   5.  Vetting Process Procedures  . . . . . . . . . . . . . . . . .   5
   6.  Selective Disclosure JSON Web Tokens (SD-JWT) for Vetted
           information . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  SD-JWT and Disclosures  . . . . . . . . . . . . . . . . .   7
     6.2.  SD-JWT Verification . . . . . . . . . . . . . . . . . . .   7
     6.3.  Vesper token SD-JWT and SD-JWT+KB Data Formats  . . . . .   7
     6.4.  Example Issuance  . . . . . . . . . . . . . . . . . . . .   8
   7.  API Endpoints . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Request Vetting Token API . . . . . . . . . . . . . . . .  15
     7.2.  Public API for Verifiers  . . . . . . . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16

Wendt & Sliwa           Expires 27 December 2024                [Page 2]
Internet-Draft                   vesper                        June 2024

   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  16
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   The Secure Telephone Identity (STI) architecture fundamentally
   defined by STI certificates in [RFC8226], PASSporTs in [RFC8225], and
   the SIP Identity header field [RFC8224] describe a set of constructs
   and protocols for the use of tokens and digital signatures to protect
   the integrity and provide non-repudiation of information as part of a
   communications session most notably the associated telephone numbers.
   This document extends that architecture to address the association of
   a telephone number to a persona (e.g. a person or business entity)
   given responsibility for the right to use that telephone number.
   Recently, the illegitimate use of telephone numbers by unauthorized
   parties and the associated fraudulent activity associated with those
   communications has generally eroded trust in communications systems.
   Further, basic reliance on the trust of the signer alone to at the
   time of the communications without has proven to require time and
   people consuming work to perform after-the-fact investigation and
   enforcement activities.  Other industries, like the financial
   industry, have adopted well-known successful practices of Know Your
   Customer (KYC) or Know Your Business (KYB), otherwise referred to as
   the application of vetting practices of an entity.  This document
   focuses on the representation of the vetting results and the
   information vetted for the responsible parties before any
   communications can be initiated.  The confirmation and
   acknowledgement of the connection between a persona or business
   entity with a telephone number and the responsibilities associated
   with its use is a critical step towards building true trusted
   relationships between parties involved in a set of communications.
   This document describes the "vesper" token, a VErifiable Sti PERsona
   represented by a token signed by a party that can be used as an
   acknowledged and trusted as part of a communications ecosystem to
   represent the output of the KYC or vetting procedures likely
   corresponding to an agreed upon set of policies defined by a
   communications ecosystem.  Additionally, the use of detailed vetting
   information required to verify a persona is information that likely
   requires strict privacy practices and policies to be enforced.  The
   vesper token and architecture provides mechanisms for providing
   selective disclosure of any personally identifying information to be
   disclosed to those that are authorized by either the persona directly
   or, for example, based on enforcement actions required for
   legitimately authorized legal or regulatory activity.

Wendt & Sliwa           Expires 27 December 2024                [Page 3]
Internet-Draft                   vesper                        June 2024

   In the current state of digital identities, the unique identifier
   used to identify the persona behind the identifier is obviously a
   critical part of using an identifier as part of a digital protocol,
   but just as important is the ability to associate a real-world
   persona to that identifier as the responsible party behind that
   identifier.  The telephone number as an identifier and as part of a
   set of traditional communications services offered around the world
   has been facing a challenge of illegitimate fraud based on the lack
   of a formal framework for the explicit association of a set of
   communications to a directly responsible party.  The use of
   "spoofing" of telephone numbers, a practice of the use of telephone
   numbers by not directly authorized parties, while having very
   legitimate use-cases, has been exploited by actors of fraudulent
   intent to either impersonate the legitimate party, or simply
   obfuscate the actual party behind the call.  Fraud and illegitimate
   activity has proliferated based on the loose connection of telephone
   numbers to responsible parties.

   The use of vesper tokens in communications will allow for a trust
   model enabled by a three party trust system based on an agreed set of
   vetting policies with a set of privacy enabled features to allow for
   selective disclosure for communications that require authorized use
   of a telephone number with the ability to support use-cases that
   require anonymity all the way up to full disclosure of vetted persona
   information if that is desired.  The Vetting Agent (VA) issues the
   vesper token as the party taking responsibility to vet Vetting
   Parties according to a set of policies and best practices, the
   Vetting Entity (VE) holds the resulting token or ability to provide
   access to a fresh token for proof and disclosure that they were
   vetted by the VA, and Vetting Verifier (VV) verifies the token based
   on trust that the VA is reputable and follows policies and best
   practices.  The Vesper token is primarily designed to be used in many
   ways to represent the vetting of the persona associated with a
   telephone number or as referred to more generally an STI.  This
   document defines the specific use of the vesper token in the STI
   architecture.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Wendt & Sliwa           Expires 27 December 2024                [Page 4]
Internet-Draft                   vesper                        June 2024

3.  Overview

   The vetting process for entities involves verifying their identity
   and legitimacy, typically through KYC and KYB vetting procedures.
   This document proposes a standardized method for representing the
   results of these vetting procedures using JSON Web Tokens (JWT) and
   Selective Disclosure JWT (SD-JWT).  This document does not address
   how the KYC/KYB should be performed or what documents or processes
   should be used.  Rather the goal of this document is to create a
   standardized identifier for the Vetted Entities (VE) to present that
   they are who they claim to be.

4.  Vetting Process Overview

   The vetting process is much about registration and authentication of
   a Vetting Entity (VE) with a Vetting Authority (VA).  The VE makes
   claims about themselves to prove whom they are and associated claims
   that should be vetted by the VA and will be used to make trusted
   disclosures to at Vetting Verifier (VV).  The vesper token is issued
   with that set of selectively disclosable claims to formalize that the
   information has been vetted and represents the VE accurately.

5.  Vetting Process Procedures

   The vetting process generally involves the following steps:

   Placeholder for diagram

   Setup and registration of VE with VA

   1.  Registration of the Vetting Entity (VE) with a Vetting Authority
       (VA).  The VE creates an authenticated account relationship with
       the VA and a unique entity_id is created.

   2.  The VE submits a set of information to describe itself with
       uniquely identifiable entity specific information.  This document
       describes a baseline set of information claims that SHOULD be
       included, but anticipates future specifications that correspond
       to future communications ecosystem policies and best practices
       that may extend that set of information including the syntax and
       definitions.  The submittal of information to the VA is
       RECOMMENDED to follow the format and syntax of what will be
       defined later in the document as the token claim format for each
       set of information, but this document does not specifically
       define a protocol for the submission of information, only the
       token that represents the results of the process.

Wendt & Sliwa           Expires 27 December 2024                [Page 5]
Internet-Draft                   vesper                        June 2024

   3.  The VA performs the vetting functions and KYC/KYB checks
       according to their procedures.  The vetting functions are
       something that can be performed in many ways in different
       countries and legal jurisdictions and therefore this document
       does not specify any specifics to how the VA performs these
       vetting functions and is out of scope of this document.

   RECOMMENDED but optional use of Key Binding (KB) as defined in
   [I-D.ietf-oauth-selective-disclosure-jwt]:

   1.  The entity generates a public/private key pair or the VA does it
       on the entries behalf.

   2.  The public key is registered with the VA.

   VA publishes vetted information digest to transparency service

   1.  The VA creates hash of their vetting data and/or results.  What
       exactly is included in generation of the hash is up to VA and
       influenced by the process used.

   2.  The VA logs the hash of the KYC/KYB data with a transparency
       service and issues a transparency receipt.

   3.  VE acts as a holder of Vetting Credentials and provides a method
       for verifiers to request the vetted information.  Optionally, the
       VE can use VAs hosted wallet service APIs if available.

   VE initiates communications requiring a valid and fresh token with
   required disclosures

   1.  The VA issues an SD-JWT containing the KYC/KYB information, the
       public key in CNF claim (per SD-JWT RFC draft), and the
       transparency receipt.

   VV Verification procedures

   1.  VV ensures that token signature is correct.  Optionally, if Key
       Binding is used, VV validates KB-JWT.

   2.  VV can verify the Transparency log signature to further trust the
       token.

Wendt & Sliwa           Expires 27 December 2024                [Page 6]
Internet-Draft                   vesper                        June 2024

6.  Selective Disclosure JSON Web Tokens (SD-JWT) for Vetted information

   This document defines the vesper token using the SD-JWT, defined in
   [I-D.ietf-oauth-selective-disclosure-jwt].  The vetting process and
   disclosure of information closely follows the SD-JWT Issuance and
   Presentation Flow, Disclosure and Verification, and generally the
   three-party model (i.e.  Issuer, Holder, Verifier) defined in that
   document.  The Issuer in the context of the vesper token is the VA,
   the Holder corresponds to the VE, and the Verifier is the VV.

6.1.  SD-JWT and Disclosures

   SD-JWT is a digitally signed JSON document containing digests over
   the selectively disclosable claims with the Disclosures outside the
   document.  Disclosures can be omitted without breaking the signature,
   and modifying them can be detected.  Selectively disclosable claims
   can be individual object properties (name-value pairs) or array
   elements.  When presenting an SD-JWT to a Verifier, the Holder only
   includes the Disclosures for the claims that it wants to reveal to
   that Verifier.  An SD-JWT can also contain clear-text claims that are
   always disclosed to the Verifier.

   To disclose to a Verifier a subset of the SD-JWT claim values, a
   Holder sends only the Disclosures of those selectively released
   claims to the Verifier as part of the SD-JWT.  The use of Key Binding
   is an optional feature.

6.2.  SD-JWT Verification

   The Verifier receives either an SD-JWT or an SD-JWT+KB from the
   Holder, verifies the signature on the SD-JWT (or the the SD-JWT
   inside the SD-JWT+KB) using the Issuer's public key, verifies the
   signature on the KB-JWT using the public key included (or referenced)
   in the SD-JWT, and calculates the digests over the Holder-Selected
   Disclosures and verifies that each digest is contained in the SD-JWT.

6.3.  Vesper token SD-JWT and SD-JWT+KB Data Formats

   An SD-JWT is composed of

   *  an Issuer-signed JWT, and

   *  zero or more Disclosures.

   An SD-JWT+KB is composed of

   *  an SD-JWT, and

Wendt & Sliwa           Expires 27 December 2024                [Page 7]
Internet-Draft                   vesper                        June 2024

   *  a Key Binding JWT.

   The serialized format for the SD-JWT is the concatenation of each
   part delineated with a single tilde ('~') character as follows:

   <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~

   The serialized format for an SD-JWT+KB extends the SD-JWT format by
   concatenating a Key Binding JWT.

<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~<KB>

   The payload of a vesper token as an SD-JWT is a JSON object according
   to the following rules:

   The payload MAY contain the _sd_alg key described in Section 5.1.1 of
   [I-D.ietf-oauth-selective-disclosure-jwt].  The payload MAY contain
   one or more digests of Disclosures to enable selective disclosure of
   the respective claims, created and formatted as described in
   Section 5.2.  The payload MAY contain one or more decoy digests to
   obscure the actual number of claims in the SD-JWT, created and
   formatted as described in Section 5.2.5.  The payload MAY contain one
   or more non-selectively disclosable claims.  The payload MAY contain
   the Holder's public key(s) or reference(s) thereto, as explained in
   Section 5.1.2.  The payload MAY contain further claims such as iss,
   iat, etc. as defined or required by the application using SD-JWTs.

   In order to represent the vetted claim information about a VE.  The
   SD-JWT MUST include the following claims:

   iss: Issuer, the Vetting Agent. sub: Subject, the vetted entity
   represented by a unique entity_id iat: Issuance timestamp. exp:
   Expiry timestamp. kyc_data_hash: Hash of the KYC/KYB data.
   transparency_receipt: Transparency receipt issued by the transparency
   service. (optional) cnf: Public key of the vetted entity, only if key
   binding is required, defined in [RFC7800]

6.4.  Example Issuance

   The Issuer is using the following input claim set:

Wendt & Sliwa           Expires 27 December 2024                [Page 8]
Internet-Draft                   vesper                        June 2024

   {
     "sub": "Business_42",
     "telephone_number_rtu": [
       +18001231234,
       +18881231234
     ],
     "rcd": [
       {"nam":"Business_42","icn":"https://example.com/logo.png"}
     ]
     "business_ids": [
       {"EIN":"123456789"}
     ]
     "address": {
       "street_address": "123 Main St",
       "locality": "Anytown",
       "region": "Anystate",
       "country": "US"
     },
     "contact_given_name": "John",
     "contact_family_name": "Doe",
     "contact_email": "johndoe@example.com",
     "contact_phone_number": "+12025550101"
   }

   The Issuer in this case made the following decisions:

   *  The "telephone_number_rtu" array and contents is always visible.

   *  The "rcd" array is always visible, but its contents are
      selectively disclosable.

   *  The sub element and essential verification data (iss, iat, cnf,
      etc.) are always visible.

   *  All other claims are selectively disclosable.

   *  For address, all of the claims can only be selectively disclosed
      in full.

   The following payload is used for the SD-JWT:

Wendt & Sliwa           Expires 27 December 2024                [Page 9]
Internet-Draft                   vesper                        June 2024

{
  "_sd": [
    "CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI",
    "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
    "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI",
    "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
    "XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM",
    "XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE",
    "gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM",
    "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4"
  ],
  "iss": "https://vetting-agent.example.com",
  "iat": 1683000000,
  "exp": 1883000000,
  "sub": "Business_42",
  "telephone_number_rtu": [
    +18001231234,
    +18881231234
  ],
  "rcd": [
    {
      "...": "pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo"
    }
  ],
  "business_ids": [
    {
      "...": "7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0"
    }
  ],
  "kyc_data_hash": "8khAv1U1OSlerP0VkBJrWZ07Cf6JkPudry3lcbwHgeZ",
  "transparency_receipt": "dh-ko8aIKQc9DlGzhaVYopFndjkZ_VCzmyTa6UjlZo3",
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}

   The following Disclosures are created by the Issuer:

   Claim contact_given_name:

Wendt & Sliwa           Expires 27 December 2024               [Page 10]
Internet-Draft                   vesper                        June 2024

   SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4
   Disclosure:
   WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o
   biJd
   Contents: ["2GLC42sKQveCfGfryNRN9w", "contact_given_name", "John"]

   Claim contact_family_name:

   SHA-256 Hash: TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo
   Disclosure:
   WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRv
   ZSJd
   Contents: ["eluV5Og3gSNII8EYnsxA_A", "contact_family_name", "Doe"]

   Claim contact_email:

SHA-256 Hash: JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE
Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VA
ZXhhbXBsZS5jb20iXQ
Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "contact_email", "johndoe@example.com"]

   Claim phone_number:

   SHA-256 Hash: PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI
   Disclosure:
   WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIr
   MS0yMDItNTU1LTAxMDEiXQ
   Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "contact_phone_number",
   "+1-202-555-0101"]

   Claim business_ids:

   SHA-256 Hash: XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM
   Disclosure:
   WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJp
   ZmllZCIsIHRydWVd
   Contents: ["Qg_O64zqAxe412a108iroA", "business_ids", true]

   Claim address:

Wendt & Sliwa           Expires 27 December 2024               [Page 11]
Internet-Draft                   vesper                        June 2024

   SHA-256 Hash: XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE
   Disclosure:
   WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVl
   dF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRv
   d24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0
   Contents: ["AJx-095VPrpTtN4QMOqROA", "address", {"street_address":
   "123 Main St", "locality": "Anytown", "region": "Anystate",
   "country": "US"}]

   Array Entry:

SHA-256 Hash: pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo
Disclosure: WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0
Contents: ["lklxF5jMYlGTPUovMNIvCA", "{"nam":"Business_42","icn":"https://example.com/logo.png"}"]

   Array Entry:

   SHA-256 Hash: 7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0
   Disclosure: WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0
   Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "123456789"]

   The payload is then signed by the Issuer to create a JWT like the
   following:

   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
   IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
   akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
   dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
   SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
   TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
   Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
   b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
   bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
   Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
   InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
   VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
   ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
   InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
   NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
   ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
   MkhaUSJ9fX0.XaB1KmNGBE-uKjT8M3VSu65QVWdNMjuhJI1sIEM4TIEs6Ae2f0DfWP80
   TAg79QIhbz04IIrrXyrEbzkeZLoVHQ

   The issued SD-JWT might look as follows:

   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
   IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
   akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL

Wendt & Sliwa           Expires 27 December 2024               [Page 12]
Internet-Draft                   vesper                        June 2024

   dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
   SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
   TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
   Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
   b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
   bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
   Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
   InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
   VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
   ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
   InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
   NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
   ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
   MkhaUSJ9fX0.XaB1KmNGBE-uKjT8M3VSu65QVWdNMjuhJI1sIEM4TIEs6Ae2f0DfWP80
   TAg79QIhbz04IIrrXyrEbzkeZLoVHQ~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgI
   mdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZh
   bWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWl
   sIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhR
   IiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNjR6cUF4Z
   TQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZCIsIHRydWVd~WyJBSngt
   MDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjog
   IjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFu
   eXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZR
   IiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5
   YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMDAwXQ~WyJsa2x4RjVqTVlsR1RQVW92T
   U5JdkNBIiwgIlVTIl0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0~

   Presentation

   The following non-normative example shows an SD-JWT+KB as it would be
   sent from the Holder to the Verifier.  Note that it consists of six
   tilde-separated parts, with the Issuer-signed JWT as shown above in
   the beginning, four Disclosures (for the claims given_name,
   family_name, address, and nationalities) in the middle, and the Key
   Binding JWT as the last element.

Wendt & Sliwa           Expires 27 December 2024               [Page 13]
Internet-Draft                   vesper                        June 2024

   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
   IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
   akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
   dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
   SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
   TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
   Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
   b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
   bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
   Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
   InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
   VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
   ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
   InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
   NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
   ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
   MkhaUSJ9fX0.XaB1KmNGBE-uKjT8M3VSu65QVWdNMjuhJI1sIEM4TIEs6Ae2f0DfWP80
   TAg79QIhbz04IIrrXyrEbzkeZLoVHQ~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgI
   mZhbWlseV9uYW1lIiwgIkRvZSJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFk
   ZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5
   IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMi
   fV0~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd
   ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCA
   idHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodH
   RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MTgyOTg3NjYsICJzZF
   9oYXNoIjogImEyWTh0bUhrUm9MQXFrWTlKMjR0aXhucWJNLVVxcFg2MUpJRm5BVDIxX2
   sifQ.sqzbrv_SfCuI7yk3w7Hot82zFZiaWB-EH2GqsSi2-ZukcgP7z8DQGhPkSV97-WZ
   r5hGm-nR0MmSDTXgmoFeViQ

   The following Key Binding JWT payload was created and signed for this
   presentation by the Holder:

   {
     "nonce": "1234567890",
     "aud": "https://verifier.example.org",
     "iat": 1718298766,
     "sd_hash": "a2Y8tmHkRoLAqkY9J24tixnqbM-UqpX61JIFnAT21_k"
   }

   If the Verifier did not require Key Binding, then the Holder could
   have presented the SD-JWT with selected Disclosures directly, instead
   of encapsulating it in an SD-JWT+KB.

7.  API Endpoints

   The vetting service provides the following APIs:

Wendt & Sliwa           Expires 27 December 2024               [Page 14]
Internet-Draft                   vesper                        June 2024

7.1.  Request Vetting Token API

Endpoint: /api/request-vetting-token
Method: POST
Description: Requests a vetting token (SD-JWT) from the Vetting Authority (VA).
Headers:
  Authorization: Bearer (VE's m2m bearer token)

   Request Body:

   {
     "entity_id": "unique-entity-id",
     "key_binding": true,
     "public_key_jwk": {
       "kty": "RSA",
       "e": "AQAB",
       "n": "lsO0Qe0Qu7FwZQ22T5vlqXN...",
       "alg": "RS256"
     }
   }

   Response:

   {
     "status": "success",
     "vetting_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
     "transparency_receipt": {
       "log_entry_id": "transparency-log-001",
       "receipt": {
         "hash": "abc123...",
         "timestamp": "2024-06-11T12:35:00Z",
         "signature": "transparency-service-signature"
       }
     }
   }

   Note: entity_id is generated by VA.  The mechanism how persona is
   vetted is not subject of this document.  This API can only be called
   after the vetting was complete and entity_id was issued.

7.2.  Public API for Verifiers

   Endpoint: /api/verify-vetted-info
   Method: POST
   Description: Verifies the validity of transparency receipt.
   Request Body:

Wendt & Sliwa           Expires 27 December 2024               [Page 15]
Internet-Draft                   vesper                        June 2024

   {
     "transparency_receipt": {
       "log_entry_id": "transparency-log-001",
       "receipt": {
         "hash": "abc123...",
         "timestamp": "2024-06-11T12:35:00Z",
         "signature": "transparency-service-signature"
       }
     }
   }

   Response:

   {
     "status": "success",
     "message": "Vetted information verified successfully."
   }

8.  Security Considerations

   TODO Security

9.  IANA Considerations

   This document has no IANA actions.

10.  Normative References

   [I-D.ietf-oauth-selective-disclosure-jwt]
              Fett, D., Yasuda, K., and B. Campbell, "Selective
              Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-
              Draft, draft-ietf-oauth-selective-disclosure-jwt-09, 13
              June 2024, <https://datatracker.ietf.org/doc/html/draft-
              ietf-oauth-selective-disclosure-jwt-09>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/rfc/rfc7800>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Wendt & Sliwa           Expires 27 December 2024               [Page 16]
Internet-Draft                   vesper                        June 2024

   [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
              "Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 8224,
              DOI 10.17487/RFC8224, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8224>.

   [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8225>.

   [RFC8226]  Peterson, J. and S. Turner, "Secure Telephone Identity
              Credentials: Certificates", RFC 8226,
              DOI 10.17487/RFC8226, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8226>.

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Chris Wendt
   Somos, Inc.
   United States of America
   Email: chris@appliedbits.com

   Rob Sliwa
   Somos, Inc.
   United States of America
   Email: robjsliwa@gmail.com

Wendt & Sliwa           Expires 27 December 2024               [Page 17]