Device in response object need to be omitted or clearer defined

[hdamker]

Problem description

The SessionInfo object within responses contains the Device object.

As raised in several comments, but lately by @jlurien as comment in the context of PR #325:

• we have not stated explicitly if the identifiers in the response must always be the same identifiers that were indicated in the creation request
• IP addresses may be reassigned and they may no longer identify the same device at all moments
• if we decide to map to a permanent identifier, such a MSISDN, and we return it, we may be disclosing private and unnecessary information to the client

Expected behavior

Don't return the Device object within the sessionInfo
or define a clear behaviour which avoids the above problems

Alternative solution

Make the device parameter within SessionInfo optional and leave the details to implementations
Note: #326 does make the device parameter optional both for CreateSession and SessionInfo (as it is included in BaseSessionInfo)

Additional context

But the concept of Device as property of current SessionInfo triggers many questions that we probably need to tackle for future releases. So far we ask the device to be returned as part of sessionInfo in responses, but we have not stated explicitly if the identifiers in the response must always be the same identifiers that were indicated in the creation request. Moreover, IP addresses may be reassigned and they may no longer identify the same device at all moments. Also, if we decide to map to a permanent identifier, such a MSISDN, and we return it, we may be disclosing private and unnecessary information to the client.

Originally posted by @jlurien in #325 (comment)

[jlurien]

With the pressure to decide something for the meta-release, the safest approach would be to attach to sessionInfo the same device value that was passed in createSession request. That would imply that if device was omitted, no device must be returned. If a device was included, keep the same values and state that those were the original values at the time of creation. That would work for GET /sessions/{sessionId}

For the endpoint that retrieve sessions by device, there may be corner cases and it would be up to the implementation to be able to find the session or return and error or empty array. For example, if session was created with certain IPs and now IPs are different, implementation may be able to know that they identify the same device and return it or no. For many usual cases were phoneNumbers are used, it should not be a problem and I think we shouldn't limit functionality for the most common cases because of the corner ones.

[eric-murray]

If a 3-legged token is being used, the service API will (probably) not know what end user identifiers were used to generate that token. But both the API provider and client will know the sub (subject) claim of the ID token.

So, for that scenario, I'd suggest to use the sub claim (a string) as the end user identifier in the session info. Indeed, this could be generalised to the 2-legged token case, though in that case we don't get the sub calculated for "free" by OIDC, and hence would need to calculate that separately.

I agree it is too late for the meta-release, so I also agree that only device identifiers explicitly provided by the API client should be stored in the session info.

In fact, I would go further, and say that only one "identifier" (it might be a value pair) should be in the session info, which identifier being decided by the API provider. This is because of Commonalities Issue 259. We cannot now return 422 - DEVICE_IDENTIFIERS_MISMATCH (otherwise the API consumer will learn that a given ipv4address is not being used by a given phoneNumber), so better to accept one and ignore the rest.

I've not thought about IP address re-assignment, but my instinct is that, if the device gets allocated a new public IPv4 address or IPv6 routing prefix, then the session should be terminated and then re-created for the new address.

[hdamker]

The issue at hand is addressed with hdamker@b349cda.

Further potential information leaks, e.g. by an error message when 3-legged token and a device identifier within the request do not match, are under discussion within camaraproject/Commonalities#259.