Clarification on registration GET with deviceId | webrtc-registration

[teikuran]

Problem description
Since deviceId is a client generated identifier, it cannot be assumed to be globally unique. If multiple registration entries exist for the same deviceId but different phoneNumbers, the API may return a registration entry associated with a phoneNumber other than the one authorized by the access token.

As a result, a client could obtain another user's registration information.

The API should ensure that the returned registration entry is associated with the phoneNumber authorized by the access token, rather than selecting an entry based solely on deviceId.

Issue example as following:

`GET /webrtc-registration/vwip/sessions?deviceId={deviceId#X} HTTP/1.1
Host: ...
Authorization: Bearer <access_token>
x-correlator: ...
Accept: application/json`

`HTTP/1.1 200 OK
Content-Type: application/json
x-correlator: ...

[
  {
    "regInfo": {
      "phoneNumber": "+8190xxxxxxxx", -> the user A's phone number registered with the deviceId#X generated by API client-1
      "regStatus": "Registered"
    },
    "registrationId": "a1b2c3d4-1234-5678-abcd-ef0123456789",
    "expiresAt": "2026-05-05T13:32:17.358Z"
  },
  {
    "regInfo": {
      "phoneNumber": "+8190yyyyyyyy", -> another user A's phone number registered with the deviceId#X generated by API client-1
      "regStatus": "Registered"
    },
    "registrationId": "c3d4e5f6-9012-3456-cdef-0123456789ab",
    "expiresAt": "2026-05-05T13:45:00.000Z"
  },
  {
    "regInfo": {
      "phoneNumber": "+81zzzzzzzz", -> the user B's phone number registered with the deviceId#X generated by API client-2
      "regStatus": "Registered"
    },
    "registrationId": "b2c3d4e5-5678-9012-efab-cd0123456789",
    "expiresAt": "2026-05-05T14:00:00.000Z"
  }
]`

Expected behavior

paths:
  /sessions:
    get:
      tags:
        - Registration
      summary: Retrieve all registrations for a device
      description: |-
-        Retrieve all active registrations associated with a given `deviceId`.
+       Retrieve the active registrations associated with a given `deviceId`
+       that are authorized for the access token used in the request.

        This endpoint allows an API consumer to recover registration state
        after a network disconnection or application restart, where the
        `registrationId` has been lost but the `deviceId` is known.

+       Because `deviceId` is a client-generated identifier and is NOT
+       guaranteed to be globally unique, the same `deviceId` value may be
+       shared across registrations bound to different `phoneNumber`s. Only
+       the registrations bound to a `phoneNumber` authorized by the access
+       token are returned; registrations bound to any other `phoneNumber`
+       are not included in the response.

        Returns an empty array if no active registrations exist for the
        given `deviceId`. It is not possible to retrieve registrations
        belonging to other devices.

And an editorial error as follows ("gh" can not be used as UUID's hexadecimal characters per RFC)

              examples:
                MultipleRegistrations:
                  summary: Device with multiple active registrations (multi-MSISDN)
                  value:
                    - regInfo:
                        phoneNumber: "+123456789"
                        regStatus: Registered
                      registrationId: "a1b2c3d4-1234-5678-abcd-ef0123456789"
                      expiresAt: "2026-05-05T13:32:17.358Z"
                    - regInfo:
                        phoneNumber: "+198765432"
                        regStatus: Registered
-                      registrationId: "b2c3d4e5-5678-9012-efgh-ab0123456789"
+                     registrationId: "b2c3d4e5-5678-9012-efab-ab0123456789"
                      expiresAt: "2026-05-05T14:00:00.000Z"

[stroncoso]

Hi @teikuran ,

Two cases:

• On the 3-legged access token, the sole deviceId is enough, it should resolve only to one deviceId+phoneNumber, so a unique registrationId.
• On the 2-legged access token, you are right, like it happens on the registration use case, now, we need to have phoneNumber as a mandatory field on the GET.

So on the second case, we have multiple devices, and the bad luck that 2 of them share UUID. When returning the registration, I would assume that the GW will confirm via the token info that the registration is part of the domain and correspond with that user... And also you can reject the registration for that deviceId if you already have that deviceId on another domain.

We can also review the comments around the "POST /registration" command, and reject any deviceId already used on other domain.

note: What I'm trying to avoid is to include the phoneNumber on the URL. Becaus, I need to re-review it, but I think that it is not allowed.

Best regards,