Ambiguous definition for IdP errors

[dontcallmedom]

Initially raised by @soareschen at w3c/webrtc-pc#1511

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 RTCErrors 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.

[dontcallmedom]

Comment by @fluffy

@martinthomson - have a look at this