lowering UA requirements

[Tim Kuijsten]

The current specification of BrowserID makes a big assumption on the
powers of the UA. It has to have an on-board html5 rendering and
javascript engine and do all interaction with IdPs and RPs by exposing
the navigator.id API. I see the following major benefits of this approach:
1. every IdP can implement and host their own completely custom web
based login flow
2. there is a natural separation between the RP and the IdP by
enforcing existing browser origin policies

There are also a few downsides to this approach:
1. it places heavy requirements on the UA, since it has to run a
complete html5 rendering- and JS-engine so it can render the IdPs
authentication and provisioning pages
2. albeit flexible for the IdP in that a custom web flow can be
designed, a non-custom-webbased flow is impossible. For e-mail only
providers that offer traditional authentication via smtp and sasl, this
can be a bridge too far.
3. it's hard to come up with a mobile app sdk for iOS and Andriod
because of the switching to the browser to login and then back to the
app without interrupting the app UX. If a mobile app could use a simple
REST interface for authentication and provisioning instead of running
the js engine on IdPs pages, this would make building mobile apps with
browserid much simpler and possible on a short term.

I'm not sure a rather "fat" client with html5 rendering and javascript
execution power is really needed in order to realize the concepts behind
BrowserID. I'm wondering if we can make a much lighter agent, that lacks
support for modern html5 if we make some adjustments to the protocol.
This can even short circuit a lot of the problems and workarounds
currently needed to make html5 popups work across different devices,
browsers and platforms.

In other words, I'm not convinced that mixing a fully fledged browser in
the BrowserID protocol is a necessity.

I worked out a small idea I have about a more RESTful approach that
offers alternatives to the custom-webbased-only login flow IdPs are
currently bound to. Please shoot on it:
https://etherpad.mozilla.org/c742JNtM

[Luke Howard]

It's a very interesting idea, particularly for the GSS BrowserID mechanism. It means we could do a completely native implementation.

Notes:

I wouldn't say that implementing the browser authentication way is necessarily more difficult than the REST way, or that this is a bridge too far for SASL clients: displaying an embedded browser during the SASL authentication exchange is reasonably trivial, at least on non-mobile platforms, and actually saved us a considerable amount of effort by sharing the existing implementation.

How does this work if your IdP requires some form of initial authentication that cannot be accomplished without a browser? Also, the lack of branding chrome might discourage some IdPs from supporting this.

-- Luke

PS. I see you included "gss" as a REST based authentication method. Were you referring to www.w3.org/2011/identity-ws/.../idbrowser2011_submission_16.pdf? This no doubt would make Nico happy :-)

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

--
Luke Howard / lu...@padl.com
www.padl.com / www.lukehoward.com

[Ben Adida]

Hi Tim,

In fact, we are considering a defined-protocol approach for what I've been
calling "IdP+". The reasoning is a bit different than the one you offer,
and has more to do with the thinking we've been doing on PICL (Profile In
the Cloud) and what it means to log into your browser.

Three reasons why I'm not convinced yet that we should do this for the
basic Persona use case:
(a) I don't think this REST approach to IdPs would work well in unmodified
modern browsers. Do you see a way that it might work?
(b) a webview is no longer a "heavy requirement", and in fact we're
developing SDKs for iOS and Android that simply do webview embedding, which
is relatively easy in both cases
(c) having protocol flexibility with the IdP is a really big win that can't
be understated.

The biggest issue is, of course (a). It seems to me much easier to have
email providers provide *some* kind of HTML interface if they want to talk
Persona, than it is to define a world where certain IdPs won't work in
unmodified browsers. That seems like a clear no-go. Can you think of a way
around this problem?

-Ben

> https://etherpad.mozilla.org/**c742JNtM<https://etherpad.mozilla.org/c742JNtM>
> ______________________________**_________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>

[Lloyd Hilaiel]

On Feb 28, 2013, at 4:41 AM, Ben Adida <b...@adida.net> wrote:

> The biggest issue is, of course (a). It seems to me much easier to have
> email providers provide *some* kind of HTML interface if they want to talk
> Persona, than it is to define a world where certain IdPs won't work in
> unmodified browsers. That seems like a clear no-go. Can you think of a way
> around this problem?

What about making cors support required?

I'm also worried about a world where not all clients work with all Idps. This happens when rest is optional for Idps and web is optional for clients.

That said I'm highly sympathetic to the high level goals, and predict we will talk about this more as we work with other vendors to implement native client support for persona...

Lloyd