Proposed text on network-based authentication

[AxelNennker]

There is no OAuth sub in OAuth2.
There is an id_token.sub in OIDC.

Network authentication identifies the subscription which is primarily defined by the IMSI.
If there is a one-to-one relationship between between IMSI and MSISDN then network authentication also identifies the MSISDN. If one subscriber has multiple SIMs with the same MSISDN then things might go wrong for the Camara API, because the user might want some QoD for the device they are currently using but not for the other with the same.

What type of PR is this?

• correction

What this PR does / why we need it:

• replace OAuth sub
• Describe what network authentication does
• Clarify that globally unique and long-term identifiers like MSISDN must not be handed to the API consumer in id_token.sub. Also associate sub with the access token.

[jpengar]

In the current version of https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md everything hinges on network-based authentication.
Which is not enough for user consent because network-based "authentication" identifies the subscription not the user.
Maybe if "prompt=none" in combination with a some "purpose", is network-based authentication enough to decide whether user consent is "needed" or not. Otherwise the user must authenticate using some login-credentials and give consent.

Please have a look at what the document defines as User and as End User.

• End User: the human participant who uses the application from a consumption device.
• User: the client/subscriber of the telco operator, identified by a unique user identifier (e.g. subject identifier sub in OpenID Connect terminology). The user is the resource owner. Usually the user corresponds to the end user, but this is not always the case. For example, a parent may be the user of a mobile subscription for their children.

So please note that when the document refers to the user, it means the Telco Operator subscriber.

[AxelNennker]

Clarified the PR description.

[AxelNennker]

In the current version of https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md everything hinges on network-based authentication.
Which is not enough for user consent because network-based "authentication" identifies the subscription not the user.
Maybe if "prompt=none" in combination with a some "purpose", is network-based authentication enough to decide whether user consent is "needed" or not. Otherwise the user must authenticate using some login-credentials and give consent.

Please have a look at what the document defines as User and as End User.

* _End User: the human participant who uses the application from a consumption device._

* _User: the client/subscriber of the telco operator, identified by a unique user identifier (e.g. subject identifier sub in OpenID Connect terminology). The user is the resource owner. Usually the user corresponds to the end user, but this is not always the case. For example, a parent may be the user of a mobile subscription for their children._

So please note that when the document refers to the user, it means the Telco Operator subscriber.

In the current version of https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md everything hinges on network-based authentication.
Which is not enough for user consent because network-based "authentication" identifies the subscription not the user.
Maybe if "prompt=none" in combination with a some "purpose", is network-based authentication enough to decide whether user consent is "needed" or not. Otherwise the user must authenticate using some login-credentials and give consent.

Please have a look at what the document defines as User and as End User.

* _End User: the human participant who uses the application from a consumption device._

* _User: the client/subscriber of the telco operator, identified by a unique user identifier (e.g. subject identifier sub in OpenID Connect terminology). The user is the resource owner. Usually the user corresponds to the end user, but this is not always the case. For example, a parent may be the user of a mobile subscription for their children._

So please note that when the document refers to the user, it means the Telco Operator subscriber.

I am not happy with the definition of "user" in documentation/CAMARA-API-access-and-user-consent.md because I find it confusing and contrary to what is usually defined to be a user by non-telco readers, but that is not part of this PR.
Readers who are API consumers might be surprised by this definition.

I say that mixing user and subscriber is a typical telco. Camara API Design guidelines tell us to avoid telco terminology. I, personally, mixing subscriber and user falls under that guideline.
Again not part of this PR.

[sebdewet]

• End User: the human participant who uses the application from a consumption device.
• User: the client/subscriber of the telco operator, identified by a unique user identifier (e.g. subject identifier sub in OpenID Connect terminology). The user is the resource owner. Usually the user corresponds to the end user, but this is not always the case. For example, a parent may be the user of a mobile subscription for their children.

I would have just said for the End User :
the human participant who uses the device. (can be through an application, a browser etc.)

And I would prefer resource owner for User.

[AxelNennker]

• End User: the human participant who uses the application from a consumption device.
• User: the client/subscriber of the telco operator, identified by a unique user identifier (e.g. subject identifier sub in OpenID Connect terminology). The user is the resource owner. Usually the user corresponds to the end user, but this is not always the case. For example, a parent may be the user of a mobile subscription for their children.

I would have just said for the End User : the human participant who uses the device. (can be through an application, a browser etc.)

And I would prefer resource owner for User.

@sebdewet please create a PR for the glossary if you think that should be a change.
Are you OK with my new text in this PR?

• Use network based authentication mechanism to obtain the subscription identifier, i.e.: MSISDN or IMSI. Set the id_token sub to some unique user ID and associate the sub with the access token. The id_token sub SHOULD not reveal information to the API consumer that they not already know, e.g. using the MSISDN as a sub might violate privacy. (Step 4).

[AxelNennker]

I think that "user" is not as specific as it can be here. Only the "unusall" definition of user in the glossary make the use of the term "user" workable. But why avoid the correct term "subscription"?

[jpengar]

I think that "user" is not as specific as it can be here. Only the "unusall" definition of user in the glossary make the use of the term "user" workable. But why avoid the correct term "subscription"?

If we commit my suggestion above (keeping the term "subscription" in that sentence), I'm fine with merging the PR. And then we can discuss the correct term to use along the document in another issue/PR as suggested here by @AxelNennker. That change would require reviewing all text along the document and we would be better off doing that in a separate PR if eventually needed. This is actually related to the existing issue #98.

In Axel's absence I could commit my suggestion and merge this PR I think, if you @sebdewet are okay with it and with what I mentioned above.

[jpengar]

LGTM

[jpengar]

I'm merging this PR as agreed in the June 19 WG meeting call, since there have been no further comments or feedback.

[sebdewet]

LGTM