Device in response object need to be omitted or clearer defined

[hdamker]

Device in response object need to be omitted or clearer defined

[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.