We're developing several specs that interact with physical devices. Several of these specs provide IDs for their devices to let web developers associate properties with the devices over time. MediaDeviceInfo takes the extra step of providing separate IDs for the "device", meaning a particular microphone, camera, speaker, etc., and for the "group", meaning a collection of devices on the same physical hardware. But media devices aren't the only thing that can come in a group, so we should be thinking about how to let web developers associate device groups between different specifications.

A particular use case for this is associating a headset's audio channels with the headset's Bluetooth settings channel.

@jan-ivar was kind enough to write down in w3c/mediacapture-main#202 some of the properties of the existing IDs:

• MediaDeviceInfo.groupId is not persisted to disk, but stable within a browser-session and not origin-unique.
• MediaDeviceInfo.deviceId is origin-unique, and persistent only when permission is granted: w3c/mediacapture-main#218
• MIDIPort.id - is persistent but may not be origin-unique.
• BluetoothDevice.id is origin-unique, not available at all until permission is granted, and persistent until permission is revoked.

Unless someone argues otherwise, I'm going to treat any lack of origin-uniqueness as a bug.

As an initial base for discussion, I'd suggest that we add a groupId property to at least BluetoothDevice, and specify that it's shared with MediaDeviceInfo.

I think we don't need the groupId to persist across browser sessions as long as the individual devices in a group do have persistent IDs, but it might be easier for developers if it is persistent. Do we make platform evolution harder in any way if the group ID is persistent?

Where should we put the algorithm for generating group IDs? How do we word that? I don't think we can specify how a UA figures out that two devices are in the same group: it'll depend a lot on the connection technologies.