[webrtc-pc] Ambiguous definition for IdP errors

soareschen has just created a new issue for https://github.com/w3c/webrtc-pc:

== Ambiguous definition for IdP errors ==
In the last step of 9.3 Requesting Identity Assertions:

> If assertion generation fails, then the promise for the corresponding function call is rejected with a newly created OperationError.

This is not consistent with several other sections.

- Section 9.5 _IdP Error Handling_ suggests that IdP-related failures would cause the corresponding method to reject with `RTCError`.

- In `createOffer` and `createAnswer`, any error from identity assertion request process would cause it to reject with `NotReadableError`.

Section 9.5 also do not distinguish well of which error is returned by the IdP proxy callback, vs which error is returned by the `RTCPeerConnection` methods. For example:

- If login is required, the IdP proxy's `generateAssertion()` should reject with `RTCError('idp-need-login')`. But is the rejection from the corresponding `getIdentityAssertion()` an `RTCError('idp-need-login')`, `RTCError('idp-execution-failure')`, or `OperationError`? It also doesn't make sense for `validateAssertion()` to throw such error.

- It seems that `RTCError('idp-token-expired')` and `RTCError('idp-token-invalid')` are to be thrown by an IdP proxy's `validateAssertion()`. So these errors have to be propogated to the corresponding `RTCPeerConnection` methods so that applications can know the failure reasons? It also doesn't make sense for `generateAssertion()` to throw such error.

- It seems that errors such as `RTCError('idp-load-failure')`, `RTCError('idp-bad-script-failure')` are to be returned only by the corresponding `RTCPeerConnection` methods. What happen if an IdP proxy return such `RTCError`s in `generateAssertion()` and `validateAssertion()`? Do those errors get propogated up to the corresponding `RTCPeerConnection` methods, or do they get swallowed and converted into generic `RTCError('idp-execution-failure')`?

- It is not clear whether attributes such as `idpErrorInfo` and `idpLoginUrl` get to propogate from IdP proxy back to the error results of `RTCPeerConnection` methods. Or do these attributes only accessible through `pc.idpErrorInfo` and `pc.idpLoginUrl`? Can a generic `Error` object having custom `idpErrorInfo` be propogated, or does it have to be `RTCError` thrown by the IdP proxy?

Some of the failure do not have defined error type. For example 9.4.9 says:

> 9. The RTCPeerConnection validates that the domain portion of the identity matches the domain of the IdP as described in [RTCWEB-SECURITY-ARCH]. If this check fails then the identity validation fails.
>
> If identity validation fails and there is a target peer identity for the RTCPeerConnection, the promise returned by setRemoteDescription MUST be rejected with the same DOMException.

So it's not clear if in such as do `setRemoteDescription` get rejected with `OperationError`?

I think the error sections can be rewritten with more concise definitions by separating them into multiple phases. And for each kind of failure, the specific type of error should be mentioned in the same step.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1511 using your GitHub account

Received on Wednesday, 26 July 2017 09:34:50 UTC