Re: Feedback from implementing identity assertions (W3C issues)

Obviously, this was super-interesting to everyone and agreement was implicit.

On 20 December 2013 17:06, Martin Thomson <martin.thomson@gmail.com> wrote:
> I'd like to have an error callback added to getIdentityAssertion():
>
>   void getIdentityAssertion(optional RTCPeerConnectionErrorCallback
> failureCallback);
>
> The alternative would be to provide an 'identityerror' event, which
> would have the benefit of letting applications know when an assertion
> couldn't be generated during createOffer/createAnswer as well, but
> that already has a clear demarcation point.  I prefer the callback.

I'm in the process of creating pull requests for this and the other
issues with the spec, and I've changed my mind with respect to the
callback on this one.  The reason relates to some issues that I'm
going to raise over in IETF-land.

When testing this stuff out, we found that the IdP proxy can be
brittle.  The best safeguard against brittleness is a timer.  A timer
is only possible if the IdP interactions don't depend on any user
interaction, which takes an indeterminable time.

It's also nice for other reasons.  We can tighten the sandbox that the
proxy operates in so that it can't generate popups.  Using the IdP
proxy as an end-run on popup-blocking was a fairly big security
concern from some quarters.

Thus, the situation arises when a user doesn't have a current cookie
(or other persistent authentication information) for the IdP or the
IdP wants to interact with the user for any reason prior to generating
an assertion.  For this, I'm proposing a LOGINNEEDED message from the
IdP.  That message will include a URL that the application will need
to load in an IFRAME to complete the login process, see [1] for
proposed text on this.

In order to surface this error, I'm going to propose that we include
an 'onidperror' event handler, with an optional argument of a
'loginurl' for this purpose.

I don't want to restrict this to just this one (albeit important) use
case.  A more generic event should be able to cover other types of IdP
error.  All that requires is that the event also include the identity
and protocol of the IdP and whether the error arose during a "SIGN" or
"VERIFY" exchange.  The message can include the information provided
by the IdP in  the "ERROR" message, if present [2].  i.e.,

[NoInterfaceObject]
interface RTCPeerConnectionIdentityErrorEvent {
  readonly attribute DOMString idp;
  readonly attribute DOMString idpProtocol;
  readonly attribute RTCIdpRequestType requestType;
  readonly attribute DOMString? loginUrl;
};

enum RTCIdpRequestType { "SIGN", "VERIFY" };


[1] https://github.com/martinthomson/ietf-drafts/commit/7367adad9ca2c7c32e642bf9bf459864bf8b0f30#diff-c2dee0dba0816fa7516eb76c465f6fe9R1588
[2] http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07#section-5.6.5.1.1

Received on Wednesday, 15 January 2014 20:10:46 UTC