jcard
Registry Context
`jcard` carries jCard contact data in the signed remediation information returned for a rejected SIP call.
Technical Summary
The `jcard` claim value is a JSON array conforming to the jCard format defined by RFC 7095. RFC 8688 registers the claim and defines its use in the JWT payload associated with a SIP 608 response.
When Used
When implementing the RFC 8688 mechanism for providing contact information through which a caller can appeal an intermediary's rejection of a SIP call.
Normative Requirements
Claim name registrant
RFC 7519 - Section 10.1.1
use a short claim name, not exceeding 8 characters without a compelling reason.
Condition: when registering a JWT claim name
it is RECOMMENDED that the name be short -- that is, not to exceed 8 characters without a compelling reason to do so
Intermediary
RFC 8688 - Section 3.2.2
include the `jcard` claim in the JWT payload.
Condition: when constructing the JWS under RFC 8688
The second JWT claim that MUST be present is the "jcard" claim.
RFC 8688 - Section 3.2.2
include at least one URL, EMAIL, TEL, or ADR property in the `jcard` claim.
Condition: when constructing the `jcard` claim
the "jcard" MUST include at least one of the URL, EMAIL, TEL, or ADR properties
UAC
RFC 8688 - Section 3.3
check the JWT's `iat` claim.
Condition: when processing the jCard
the UAC MUST check the "iat" claim in the JWT
RFC 8688 - Section 3.3
reject jCards whose `iat` value is expired under local policy.
Condition: when processing the jCard
the UAC MUST reject jCards that come with an expired "iat"
UAC supporting RFC 8688
RFC 8688 - Section 3.2.2
be prepared to receive a full jCard.
Condition: when processing the `jcard` claim
UACs supporting this specification MUST be prepared to receive a full jCard.
Validation Guidance
Match the registry claim name exactly as `jcard`; JWT claim names are case sensitive.
Verify that the claim value is a JSON array conforming to the RFC 7095 jCard format.
For an RFC 8688 JWT payload, require the `jcard` claim.
For RFC 8688 use, verify that the jCard contains at least one URL, EMAIL, TEL, or ADR property.
Ensure an RFC 8688 consumer can process a full jCard rather than only a restricted subset.
When processing an RFC 8688 jCard, check `iat` and reject it when expired under the applicable local policy.
Flag new JWT claim-name registrations longer than 8 characters unless a compelling reason is documented.
Security Notes
RFC 8688 - Section 6
A remediation jCard exposes contact information that malicious callers may use as an attack vector; RFC 8688 suggests that operators consider including it only for initiating requests that pass STIR validation.
RFC 8688 - Section 6
A malicious jCard can direct a recipient to a phishing telephone number or website. Recipients should validate whom they are communicating with, and the RFC 8688 mechanism cryptographically signs the jCard to prevent intermediary modification.
RFC 7095 - Section 6
jCard inherits the security considerations of the underlying vCard data. JSON parser flaws can also create risks, so a native, format-aware JSON parser is preferred.
Reference
Details
- Entry Id
jcard- Claim Name
jcard- Claim Description
jCard data- Change Controller
IESG- Reference
RFC8688, RFC7095