vvp-passport-1.txt

{
  "header": {
    "alg": "EdDSA",
    "typ": "passport",
    "ppt": "vvp",
    // OOBI of AID for (signing software invoked by SBC of) OP
    "kid": "https://wit1.provenant.net:5631/oobi/E0F9C28367E4011E7BA587831C1B8DEBA/witness",
  }
  "payload": {
    // originating TN in E164 format; see https://www.rfc-editor.org/rfc/rfc8225#section-5.2.1
    "orig": {"tn": ["+33612345678"]},
    // dest TN in E164 format
    "dest": {"tn": ["+33765432109"]},
    // Optional brand properties; see https://bit.ly/3DykInh
    "card": ["NICKNAME:Examples-R-Us", "CHATBOT:https://example.com/chatwithus",
      "LOGO;HASH=EK2r6EnDXre2pecTBO8s99j4OtNaaDIhVyr7uGugDhmp;VALUE=URI:https://example.com/logo64x48.png"],
    // Suboptimal. Prefer "goal" field instead of "call-reason".
    "call-reason": "schedule next appointment",
    // OOBI of dossier referencing relevant evidence. Comes from evd arg to signing service.
    "evd": "https://acme.com/E2Mr6EnDXre2pecTBO8s99j4OtNaaDIhVyr7uGugDhK4/dossier.cesr",
    "origId": "e0ac7b44-1fc3-4794-8edd-34b83c018fe9",
    "iat": 1699840000,
    //default is 30 second expiration
    "exp": 1699840030,
    // Optional. Comes from request_id arg to signing service.
    "jti": "70664125-c88d-49d6-b66f-0510c20fc3a6"
  }
}

Could you, please, check if the next example matches the VVP spec requirements:
"The signature MUST be the result of running the EdDSA algorithm over input data that consists of the following ordered metadata about a call: the source phone number (orig claim in the JWT), the destination phone number (dest claim), an OOBI for the OP (kid), a timestamp (iat), optional brand information (card with value null if missing), optional call-reason (with value null if missing), optional goal (with value null if missing), and a reference to evidence (evd)."

{
"header": {
"alg": "EdDSA",
"typ": "passport",
"ppt": "vvp",
// OOBI of AID for (signing software invoked by SBC of) OP
"kid": "https://wit1.provenant.net:5631/oobi/E0F9C28367E4011E7BA587831C1B8DEBA/witness",
}
"payload": {
// originating TN in E164 format; see https://www.rfc-editor.org/rfc/rfc8225#section-5.2.1
"orig": {"tn": ["+33612345678"]},
// dest TN in E164 format
"dest": {"tn": ["+33765432109"]},
"kid": "https://wit1.provenant.net:5631/oobi/E0F9C28367E4011E7BA587831C1B8DEBA/witness",
"iat": 1699840000,
// Optional brand properties; see https://bit.ly/3DykInh
"card": ["NICKNAME:Examples-R-Us", "CHATBOT:https://example.com/chatwithus",
"LOGO;HASH=EK2r6EnDXre2pecTBO8s99j4OtNaaDIhVyr7uGugDhmp;VALUE=URI:https://example.com/logo64x48.png"],
// Suboptimal.
"call-reason": "schedule next appointment",
// Can be null or some string value
"goal":null,
// OOBI of dossier referencing relevant evidence. Comes from evd arg to signing service.
"evd": "https://acme.com/E2Mr6EnDXre2pecTBO8s99j4OtNaaDIhVyr7uGugDhK4/dossier.cesr",
// Optional
"origId": "e0ac7b44-1fc3-4794-8edd-34b83c018fe9",
// default is 30 second expiration
"exp": 1699840030,
// Optional. Comes from request_id arg to signing service.
"jti": "70664125-c88d-49d6-b66f-0510c20fc3a6"
}
}

The example passport you show is invalid because it has kid as a claim inside the payload, in addition to it appearing as a header value. It should only appear as a header. Otherwise the passport looks fine.

The wording of the VVP spec has been simplified. The order of fields is not significant, as long as they are signed in the order they appear. The new wording is:

The signature MUST be the result of running the EdDSA algorithm over input data in the manner required by {{RFC7519}}: signature = sign(base64url(header) + "." + base64url(payload). Also per the JWT spec, the signature MUST then be base64url-encoded and appended to the other two portions of the JWT, with a . delimiter preceding it, and it MUST then be followed by ";ppt=vvp" so tools that scan the Identity header of the passport can decide how to process the passport without doing a full parse of the JWT.

See https://dhh1128.github.io/vvp/draft-hardman-verifiable-voice-protocol.html#name-pss