Re: Issue 78: IdP

I like the idea of breaking out since that could potentially make it easier
to introduce other ways of doing identity (not necessarily built on DTLS).
 But when I read the names of things, it seems more complex than it needs
to be, with some confusing names.  In fact, the more I think about it as a
separate object the, the more I think an RTPIdentifyProvider object makes
more sense:

[Constructor(DOMString provider, optional DOMString protocol)]
interface RTCIdentityProvider {
  // The IdP returns an assertion that this transport is this user at this
IdP.
  Promise<DOMString> assert(RTCDtlsTransport transport, DOMString username);

  // The IdP verifies the assertion that this transport is for this user at
this domain.
  Promise<bool> verify(DOMString assertion, RTCDtlsTransport transport,
DOMString username);
}


I think this is much more simple and straight-forward, and matches what the
IdP actually does, at least as far as I understand it.  And there are no
confusing names.  Can someone who knows IdP a little better tell me if this
makes sense?


On Thu, Jul 3, 2014 at 5:23 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> Martin Thomson said:
>
> You'll want to have a setIdentityAssertion(DOMString assertion) as well,
> since you aren't feeding this with setRemoteDescription any more.
>
> With that, you could probably remove some of the indirection.
>
> How about reducing the surface area a little:
>
> partial interface RTCDtlsTransport {
>     Promise<DOMString> getIdentityAssertion(DOMString provider, optional
> DOMString protocol = "default", optional DOMString username);
>     // this encapsulates onidentityresult and onidpassertionerror in the
> promise
>     Promise setIdentityAssertion(DOMString assertion);
>     // this encapsulates onidentityresult and onidpvalidationerror
>
>     readonly attribute RTCIdentityAssertion? peerIdentity;
> };
>
> [Robin Raymond] said:
>
> I like this API overall. I would make it its own interface though that is
> constructed from a RTCDtlsTransport to keep the security assertion stuff
> separate from DTLS, or we could make it like stats interface where "secure"
> transports could derive from...
>
> [BA]  How about this?
>
> [Constructor(RTCDtlsTransport transport)]
> interface RTCIdentity {
>     readonly    attribute RTCIdentityAssertion? peerIdentity;
>     readonly    attribute RTCDtlsTransport      transport;
>     Promise<DOMString>            getIdentityAssertion (DOMString
> provider, optional DOMString protocol = "default", optional DOMString
> username);
>     Promise<RTCIdentityAssertion> setIdentityAssertion (DOMString
> assertion);
> };
>
> dictionary RTCIdentityError {
>     DOMString  idp;
>     DOMString  protocol;
>     DOMString? loginUrl;
> };
>
> dictionary RTCIdentityAssertion {
>     DOMString idp;
>     DOMString name;
> };
>