W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2013

Feedback from implementing identity assertions (W3C issues)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 20 Dec 2013 17:06:44 -0800
Message-ID: <CABkgnnU-R5u5wWtGk7OJ+1=WSdZCMJLUQePVeUAiijwwskpoFw@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
So, I've done a little work on getting Firefox to do identity
assertions (though most of the groundwork was not mine, that I have to
credit to Max).

As usual, our APIs start out with really poor error handling until
someone actually tries to use them.  This is what I've found.

Chairs, I have some small proposals that I'd request the creation of a
tracking bug for each, below.

# learning about bad IdPs

This is an interesting problem.  Currently, when we have a bad IdP,
the only way you learn about it is that you don't get an identity
assertion with your offer or answer.  (You kinda have to look in there
to notice that you don't have an assertion in there.)

getIdentityAssertion() is worse.  If you request that this be
provided, the only possible feedback is an event if it succeeds,
though that event contains zero information.  If it fails, nothing.

## Bug 1

I'd like to have an error callback added to getIdentityAssertion():

  void getIdentityAssertion(optional RTCPeerConnectionErrorCallback

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.

# learning when identity is validated

Loading an IdP takes time.  So does validating an assertion.  For
various reasons, Firefox only does this after setRemoteDescription
succeeds.   For one, it means that we don't have to worry doing all
that work and then having to roll back if the description isn't
successfully applied.

The upshot is that in our tests, I was unable to precisely mark the
point when identity was validated so that we could check the value of
pc.peerIdentity.  This simply doesn't surface.

## Bug 2

I'd like to have the 'identityresult' event fired for any of
createOffer, createAnswer, or getIdentityAssertions.  It's also nice
if this could contain the assertion.

To that end, I'm proposing the following event definition that covers
the first case:

  dictionary RTCPeerConnectionIdentityEventInit : EventInit {
    DOMString? assertion = null;

   Constructor(DOMString type,
               optional RTCPeerConnectionIdentityEventInit eventInitDict)]
  interface RTCPeerConnectionIdentityEvent : Event {
    readonly attribute DOMString? assertion;

## Bug 3

I'd like to have a new event 'peeridentity' fired when an identity
assertion is successfully verified for the peer.  This doesn't need to
contain any attributes, because the peerIdentity will be accessible
through event.target.

  partial interface RTCPeerConnection {
    attribute EventHandler? onpeeridentity;

# peerIdentity scope

For a browser, having a single peerIdentity is fine.  But, unless we
decide that a=identity is session-scoped, a peer might provide
multiple identities.  That's not so good; we have nowhere to put them.

This suggests a more complete object model with transport objects as
has been proposed.  (Of course, implementing that will take a lot of
effort, so don't think I'm not super-excited about that prospect.
sipcc can die a flaming death.)
Received on Saturday, 21 December 2013 01:07:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC