Clarify user identification and resource access across the three APIs #233

Problem description

The three APIs don't define consistently how the user is identified, or how access to resources is restricted, for 3-legged and 2-legged access tokens:

• webrtc-call-handling: originatorAddress is required in POST /sessions for every token type (L534-L542). How it relates to the token user and to the registrationId header isn't defined, and there is no 422 MISSING_IDENTIFIER / UNNECESSARY_IDENTIFIER. The only mismatch signal is 403 INVALID_TOKEN_CONTEXT.
• webrtc-call-handling: the callee operates on a session it did not create, using the mediaSessionId from the invitation notification (L318-L320). The spec doesn't state who may GET, PUT or DELETE a session.
• webrtc-registration: POST /sessions returns 422 UNNECESSARY_IDENTIFIER for phoneNumber with a 3-legged token, but still lists 403 INVALID_TOKEN_CONTEXT (L699-L717), which no request field can trigger.
• webrtc-registration: GET /sessions?deviceId= doesn't say which registrations are returned with a 2-legged token (L149-L155). With a 3-legged token the list holds at most one item, yet the multi-registration example and the 409 recovery text assume otherwise.
• webrtc-events-subscriptions: the spec doesn't say whose events a deviceId-keyed subscription delivers. MISSING_IDENTIFIER / UNNECESSARY_IDENTIFIER are listed although the request has no user identifier.
• The deviceId definition contradicts itself across the APIs:
  • call-handling: only one registration per device (L45-L50)
  • registration: several registrations per device, "NOT guaranteed to be globally unique" (L38-L47)
  • events-subscriptions: "uniquely represents a physical device" (L10-L13)

Expected behavior

• Apply Design Guide Appendix A consistently in all three APIs, including the info.description template and the matching 422 errors. Use 403 INVALID_TOKEN_CONTEXT only where the API scope allows confirming the identity.
• Document resource access restriction per token type for every GET, PUT and DELETE, including the callee side (Design Guide 6.7).
• Use one deviceId definition in all three APIs.

Alternative solution

Additional context

Found during the review of r3.1. Some of these changes are breaking (e.g. forbidding originatorAddress with a 3-legged token) and should be made before the next public release, preferably together with the Commonalities r4.4 update.