Are "user" and "subscriber" different?

[mattfredrickson]

In KYC family API specifications, responses are described as being relative to either the "user" or the "subscriber" (and in the case if Age Verification I see both). This leads me to two questions:

1. Is the choice of language in the specification significant; are they actually different?
2. In the case where a [consumer] subscriber has multiple MSISDN's that they may issue to family members, can we expect operators to maintain records of the user, distinct from the contract holder?

[HuubAppelboom]

@mattfredrickson

1. Yes, end user and subscriber can be different. The subscriber is the contract holder, and usually telco's have only data on the contract holder.
3. In terms of privacy ((GDPR) , it would be strange to ask who the end user is, for a mobile phone subscription, because it is not needed for the execution of a contract. However, there may be local regulations that oblige to register additional end user data. I would not expect that there are many telco's that do this, and if they do it, it is very difficult to keep this up to date.

For the exact definitions of user and subscriber, see also the ICM documents where a Glossary is defined.

[mattfredrickson]

Thanks @HuubAppelboom - should the descriptions of KYC Match, KYC Fill-in and Age Verification specify subscriber then? They state "user" right now.

` title: Know Your Customer Match

description: |

This API provides the customer with the ability to compare the information it (Service Provider, SP) has for a particular mobile phone user with that on file (and verified) by the mobile phone user's Operator in their own KYC records, in order for the SP to confirm the accuracy of the information and provide a specific service to the mobile phone user.

`

` title: Know Your Customer Fill-in

description: |

This API provides the customer with the ability request and receive the information for a particular user, which on file (and verified) by the user's Operator in their own KYC records, in order for the SP to confirm the accuracy of the information and provide a specific service to the user.

`

` title: Know Your Customer Age Verification

description: |

# Summary
This API provides the customer with the ability to check if the user of the line is older than a provided age, in order to provide API customer's age-restricted services, access to its age-restricted website etc..

`

[HuubAppelboom]

In the glossary of ICM listed here https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#glossary-of-terms-and-concepts
you can see that "user" is defined as follows:

Resource Owner or User: the End-User or Subscriber which Personal Data processed by a CAMARA API relates to, the Resource Owner has the authority to authorize access to CAMARA APIs which process Personal Data.

So it can mean both End-User and Subscriber. If you want to make the definitions more clear, you should use End-User and Subscriber:

End-User: the human participant using an Application on a Consumption Device, only applicable to some CAMARA APIs.

Subscriber: the mobile subscriber of the Operator. The Subscriber is usually also the End-User, but this is not always the case. For example, a parent may be the Subscriber of a mobile subscription for their child, the End-User.

[mattfredrickson]

So it can mean both End-User and Subscriber

Therein lies the problem i'm driving at; IMO, the developer will be largely concerned with the end-user, whilst operators are likely to only hold data about the subscriber, relative to the same MSISDN .

This seems especially relevant in the context of minors who use SIMs given to them by an adult family member. I imagine, but don't know for sure, that this is a common scenario.

[HuubAppelboom]

It's not only minors, it can be any familiy member. That's the reason why the API's like Match are that granular, so you can see whether the givenName matches, Date of Birth Matches, etc, and in the Age Verification API you can get an identityMatchScore, based on the extra fields provided. This is all done to be able to recognise the end user from the subscriber.

[mattfredrickson]

I understood from your earlier comment that operators would not typically be able to recognise an end user, other than to identify that they are not the subscriber. Did I understand correctly?

If so, is this a common enough scenario to be concerned by? Should we be considering whether/how operators can register the end-user at the subscriber's discretion?

[HuubAppelboom]

These API's are designed to be used as part of a more generic onboarding process, and are often used as an extra check to prevent fraud.
In case the end user is not the subscriber (or data is not available), this will show up, and in an onboarding process, the API consumer will then typically switch to another verification method (typically with more friction).

In case you start registering end-users, you are basically upgrading towards an identity wallet (with a much higher level of assurance), and that is not what these API's are meant for. If you want to create an identity wallet, I would look at other specifications like eIDAS2.0 (in Europe). These API's are meant as a first seamless anti-fraud check, not as an identity wallet.

[mattfredrickson]

I understand your point, Huub, and I would be interested to know two things:

1. Do all operators see it the same way?
2. Is there any data to suggest what proportion of end-users are not the subscriber?

[HuubAppelboom]

@mattfredrickson
Regarding you send question, the best way to find out is implement the API's and for example record aggregate statistics with for example match.
In my experience, the percentages can vary quite a bit, depending on the target group of the use case at hand. With for example students, you often see a higher percentage where end users are not subscribers as compared to senior citizens. It may also vary per country, depending on legislation. For example, in the Netherlands 18- minors are not allowed to take out subscriptions, so minors either have (anonymous) prepaid here or they have a subscription where one of the parents is the subscriber.