From 71b4b1d42e650822b3af078283efceded21ac5b3 Mon Sep 17 00:00:00 2001 From: Ramesh Shanmugasundaram Date: Tue, 27 Jan 2026 10:37:39 +0000 Subject: [PATCH 1/4] Document jwt bearer flow trust assumptions --- documentation/CAMARA-API-access-and-user-consent.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index 5c66ebc..cf12d18 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -342,7 +342,9 @@ The JWT Bearer Flow enables an API Consumer (typically the Application Backend o **Pre-requisite:** The API Consumer must share its public key with the API Provider during onboarding, so the API Provider can verify the signature of the JWT assertion. -The API Consumer selects the User Identifier. The User is identified by the `sub` claim in the JWT assertion, which must uniquely identify the User in the Operator's system. As per the CAMARA Security and Interoperability Profile, the `sub` claim MUST be either a phone number prefixed by "tel:" or a TS.43 token prefixed by "operatortoken:". +The API Consumer selects the User Identifier. The User is identified by the `sub` claim in the JWT assertion, which must uniquely identify the User in the Operator's system. As per the CAMARA Security and Interoperability Profile, the `sub` claim MUST be either a phone number prefixed by `tel:` or a TS.43 token prefixed by `operatortoken:`. + +Unlike the `operatortoken:` prefix for the `sub` claim, which originates from a TS.43 flow and provides a stronger binding to a subscriber context, use of the `tel:` prefix in the JWT Bearer Flow relies on a pre-established trust relationship between the API Consumer and the API Provider. The mechanism by which the API Consumer obtains or verifies the phone number used in the `sub` claim is outside the scope of CAMARA specifications. Example JWT assertion, which MUST be signed by the API Consumer and MAY be encrypted: From e9fb65ee4aaabf3bebe43c67eb639d8317787b97 Mon Sep 17 00:00:00 2001 From: Ramesh Shanmugasundaram - Spry Fox Networks <90850565+sfnuser@users.noreply.github.com> Date: Wed, 28 Jan 2026 13:13:56 +0000 Subject: [PATCH 2/4] Update documentation/CAMARA-API-access-and-user-consent.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Jesús Peña García-Oliva --- documentation/CAMARA-API-access-and-user-consent.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index cf12d18..d250daa 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -344,7 +344,7 @@ The JWT Bearer Flow enables an API Consumer (typically the Application Backend o The API Consumer selects the User Identifier. The User is identified by the `sub` claim in the JWT assertion, which must uniquely identify the User in the Operator's system. As per the CAMARA Security and Interoperability Profile, the `sub` claim MUST be either a phone number prefixed by `tel:` or a TS.43 token prefixed by `operatortoken:`. -Unlike the `operatortoken:` prefix for the `sub` claim, which originates from a TS.43 flow and provides a stronger binding to a subscriber context, use of the `tel:` prefix in the JWT Bearer Flow relies on a pre-established trust relationship between the API Consumer and the API Provider. The mechanism by which the API Consumer obtains or verifies the phone number used in the `sub` claim is outside the scope of CAMARA specifications. +Unlike the `operatortoken:` prefix for the `sub` claim, which originates from a TS.43 flow and provides a stronger binding to a Subscriber context, the use of the `tel:` prefix in the JWT Bearer Flow relies on a pre-established trust relationship between the API Consumer and the API Provider. The mechanism by which the API Consumer obtains or verifies the phone number used in the `sub` claim is outside the scope of CAMARA specifications. Example JWT assertion, which MUST be signed by the API Consumer and MAY be encrypted: From 2e8999dcdfb8bef7d77754d170d985ded159360b Mon Sep 17 00:00:00 2001 From: Ramesh Shanmugasundaram Date: Thu, 29 Jan 2026 15:10:50 +0000 Subject: [PATCH 3/4] Document the limitations of tel subject claim --- documentation/CAMARA-API-access-and-user-consent.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index d250daa..ba84b0d 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -344,7 +344,7 @@ The JWT Bearer Flow enables an API Consumer (typically the Application Backend o The API Consumer selects the User Identifier. The User is identified by the `sub` claim in the JWT assertion, which must uniquely identify the User in the Operator's system. As per the CAMARA Security and Interoperability Profile, the `sub` claim MUST be either a phone number prefixed by `tel:` or a TS.43 token prefixed by `operatortoken:`. -Unlike the `operatortoken:` prefix for the `sub` claim, which originates from a TS.43 flow and provides a stronger binding to a Subscriber context, the use of the `tel:` prefix in the JWT Bearer Flow relies on a pre-established trust relationship between the API Consumer and the API Provider. The mechanism by which the API Consumer obtains or verifies the phone number used in the `sub` claim is outside the scope of CAMARA specifications. +Unlike the `operatortoken:` prefix for the `sub` claim, which originates from a TS.43 flow and provides a stronger binding to a Subscriber context, the use of the `tel:` prefix in the JWT Bearer Flow is based on a pre-established trust relationship between the API Consumer and the API Provider. Consequently, the `tel:` based subject identifier relies solely on trusted assertion and does not provide cryptographic assurance of the associated subscriber context. The mechanism by which the API Consumer obtains or verifies the phone number used in the `sub` claim is outside the scope of CAMARA specifications. Example JWT assertion, which MUST be signed by the API Consumer and MAY be encrypted: From 7064768b37ed6d2b3003dc3047171f7bea8f6562 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jes=C3=BAs=20Pe=C3=B1a=20Garc=C3=ADa-Oliva?= Date: Mon, 2 Feb 2026 09:24:16 +0100 Subject: [PATCH 4/4] Update documentation/CAMARA-API-access-and-user-consent.md --- documentation/CAMARA-API-access-and-user-consent.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index ba84b0d..d7b981d 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -344,7 +344,7 @@ The JWT Bearer Flow enables an API Consumer (typically the Application Backend o The API Consumer selects the User Identifier. The User is identified by the `sub` claim in the JWT assertion, which must uniquely identify the User in the Operator's system. As per the CAMARA Security and Interoperability Profile, the `sub` claim MUST be either a phone number prefixed by `tel:` or a TS.43 token prefixed by `operatortoken:`. -Unlike the `operatortoken:` prefix for the `sub` claim, which originates from a TS.43 flow and provides a stronger binding to a Subscriber context, the use of the `tel:` prefix in the JWT Bearer Flow is based on a pre-established trust relationship between the API Consumer and the API Provider. Consequently, the `tel:` based subject identifier relies solely on trusted assertion and does not provide cryptographic assurance of the associated subscriber context. The mechanism by which the API Consumer obtains or verifies the phone number used in the `sub` claim is outside the scope of CAMARA specifications. +Unlike the `operatortoken:` prefix for the `sub` claim, which originates from a TS.43 flow and provides a stronger binding to a Subscriber context, the use of the `tel:` prefix in the JWT Bearer Flow is applicable in scenarios where a pre-established trust relationship exists between the API Consumer and the API Provider. In this case, the API Consumer is responsible for asserting the phone number in the sub claim and for ensuring that this value accurately represents the intended Subscriber. The API Provider, in turn, relies on this trust relationship when accepting the assertion and does not independently validate the origin of the phone number. The mechanism by which the API Consumer obtains or verifies the phone number used in the `sub` claim is outside the scope of CAMARA specifications. Example JWT assertion, which MUST be signed by the API Consumer and MAY be encrypted: