2 Apps 1 User

[Michiel de Jong]

Hi,

This post continues a discussion from the Unhosted mailing list,
http://groups.google.com/group/unhosted/msg/360b30a21c34882f
where...

On Tue, Jan 17, 2012 at 4:39 AM, Ben Adida <b...@adida.net> wrote:

> I've also been toying with the idea that BrowserID could replace, in a
> user-centric way, the "dance" portion of OAuth. This is so raw I haven't
> even posted it on the dev-identity list, but since we're discussing
> OAuth here, I'm wondering what your take is? Might BrowserID be the
> right place to present a dialog that says "do you want to allow site A
> to authenticate as you to site B?"
>
> -Ben
>

Yeah, cool! I think that yes, this should probably be explored, and there
are probably several options. Just brainstorming here, and keep in mind
that IANASE :)

So say I'm signed into app A, and I see something interesting which i want
to post on my microblog, which is at app B. Now, the way that would
typically work on the web is that app A has a nascar menu of preselected
microblogging sites, so you click the right one, get an OAuth dialog, log
in to app B with your password there, and click 'Allow'.

The way this will hopefully work in the web's near future will be with web
intents, registered through an apps home screen. So a user sits down at
their browser, and the first thing they do is go to their home screen,
where they have all their installed (bookmarked) apps. App B is on there,
meaning it has had a chance to register a handler for the 'tweet this'
intent into the browser. The home screen is necessary for web intents to
work (otherwise you never have all your handlers registered), and it would
also be natural that logging into your home screen involves logging into
your BrowserID IdP. And, the home screen session could be handled by the
browser's session api, so that you can easily switch users, and multiple
people within the same household can use the home screen sessions in the
same way as they do with operating system sessions, now.

How should BrowserID play in this scenario? The default way would be that
you log into your IdP already when opening the home screen, then sign in to
app A when you open it, and then sign in to app B when you are on the
'tweet this' dialog. It might be confusing and unnecessary for the user to
authenticate to app B when they are already authenticated to app A. So
there are I think four alternatives:

the first one is quite trivial: instead of making the user click 'Sign in
with BrowserID' first, and then still click 'Tweet this' separately, you
could combine the two clicks into one, and call it 'Tweet this (triggers
BrowserID authentication)'

the second one is what i call the 'BrowserID backdoor'. It's used in the
Sauropod proposal and we almost added it into the remoteStorage spec (see
the afore mentioned thread on the Unhosted mailing list). It consists in
app A posting its own verified assertion to app B. So app B then knows that
1) the user is browsing app A right now, and 2) app A claims that the user
clicked a certain action. It could be abused, but only by sites that the
user actually signs into. This can be used for non-destructive, reversible
actions I think. I wouldn't use it for 'Tweet this', but for 'Save this
link' it would be OK. The worst that could happen is that you later go into
app B to see the links you saved, and there are some links there from an
app that you did visit, and that you did give your identity to, but that
you didn't actually want to save links from. An acceptable risk, given the
much improved click-dance flow, I think.

the third option is what i would call 'BrowserID assertion upgrade'. Given
that the browser is involved in the 'picker' that lets you choose a handler
for a certain action, at that point the browser can confirm that the user
is actually performing the action in question. So app A would tell the
browser "handle this intent, and pass them my assertion". Then the browser
would display a picker dialog where the user chooses app B. it then opens
app B, and upgrades the assertion that had app A as its audience, adding
app B as the audience now. That way, app B can know for sure that the user
wants to execute the requested intent, trusting the browser's intent
handler picker instead of trusting app A.

a variation on that would be what we could directly call 'BrowserID-aided
Web Intents', where even if the user is not signed in to app A, the Web
Intent handler picker will still tell app B what the identity of the user
is. In almost all real-world cases, you are probably OK with telling app B
who you are when you ask app B to handle an intent for you. But still, it
feels wrong to make that opt-out behavior. So maybe the intent-handler
picker should have a checkbox saying "and add my identity onto this
request". you would then have to choose which one of your identities to add
on.

So maybe the upgrade option would work better in practice than the 'aided'
version. App A probably has your identity, so it is intuitive that they are
in a position to pass that on to app B. It is then also intuitive for the
browser to slap another signature onto it in the process, just signing app
A's claim. Or you could use upgrade when the user is signed in, and fall
back to 'aided' when the user is not signed in to app A.

In conclusion, I think that yes, "2 Apps 1 User" flows like this can be
considerably improved by adding BrowserID into it.


Cheers!
Michiel

[Ian Bicking]

On Tue, Jan 17, 2012 at 1:53 AM, Michiel de Jong <mic...@unhosted.org>wrote:

> the second one is what i call the 'BrowserID backdoor'. It's used in the
> Sauropod proposal and we almost added it into the remoteStorage spec (see
> the afore mentioned thread on the Unhosted mailing list). It consists in
> app A posting its own verified assertion to app B. So app B then knows that
> 1) the user is browsing app A right now, and 2) app A claims that the user
> clicked a certain action. It could be abused, but only by sites that the
> user actually signs into. This can be used for non-destructive, reversible
> actions I think. I wouldn't use it for 'Tweet this', but for 'Save this
> link' it would be OK. The worst that could happen is that you later go into
> app B to see the links you saved, and there are some links there from an
> app that you did visit, and that you did give your identity to, but that
> you didn't actually want to save links from. An acceptable risk, given the
> much improved click-dance flow, I think.
>

I'm not sure I'm following everything here, but at least in the
Sauropod/remoteStorage case it seems like it's not so much a backdoor, as a
service that willingly lets other services use it. So let's say you give
http://storage.service.com an assertion, email "ia...@mozilla.com" and
browserid audience of http://myotherservice.com - the storage service
should really be saving your stuff under a bucket named something like
"ia...@mozilla.com@http://myotherservice.com" - that is, the data isn't
really associated with just the user's identity (ia...@mozilla.com) but also
the site they logged into. That is, no service is forced to use expect or
demand the same audience as the hostname they are served on, so long as the
site partitions things based on that audience.

Ian

[Michiel de Jong]

On Tue, Jan 17, 2012 at 7:30 PM, Ian Bicking <ia...@mozilla.com> wrote:

> it seems like it's not so much a backdoor, as a service that willingly
> lets other services use it.

good point, i shouldn't have used the term 'backdoor'; it sounds negative
and that's not what i meant to say by it. I'll refer to it as
Sauropod-style until someone comes up with a better naming for all these
options.

> no service is forced to use expect or demand the same audience as the
> hostname they are served on, so long as the site partitions things based on
> that audience.
>

i agree, that's what makes this option so interesting!


Cheers,
Michiel