W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2017

[webrtc-pc] How is port number specified when verifying peer identity's assertion?

From: Soares Chen via GitHub <sysbot+gh@w3.org>
Date: Fri, 21 Jul 2017 09:00:10 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-244606913-1500627606-sysbot+gh@w3.org>
soareschen has just created a new issue for https://github.com/w3c/webrtc-pc:

== How is port number specified when verifying peer identity's assertion? ==
rtcweb-security-arch specifies that the IdP proxy script can be located at a different port number. So for example an IdP for example.com can be located at https://example.com:8443/.well-known/idp-proxy/provider.js.

Now in `setIdentityProvider()`, it seems that the port number can be specified as part of the `provider` attribute string, together with the domain name. So we can call

pc.setIdentityProvider('example.com:8443', { protocol: 'provider.js' })

to load the correct IdP proxy.

But when the IdP proxy is returning assertion result, it is not clear how the port information is carried over. The WebIDL for `RTCIdentityAssertionResult` is:

dictionary RTCIdentityAssertionResult {
  required RTCIdentityProviderDetails idp;
  required DOMString                  assertion;

dictionary RTCIdentityProviderDetails {
  required DOMString domain;
           DOMString protocol = "default";

I am not sure if the `domain` field is the right place to specify the port number, e.g.:

  idp: {
    domain: "example.com:8443",
    protocol: "provider.js"
  assertion: "..."

Given that the assertion result is eventually serialized into the `a=identity` SDP line, and from rtcweb-security-arch it seems that the `domain` field is intended to hold the domain name only, I am not sure port number is allowed there.

If the port number is not specified in `domain`, how else would a remote peer know to load the IdP proxy script through custom port?

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1502 using your GitHub account
Received on Friday, 21 July 2017 09:00:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:35 UTC