"Connect to Backpack" flow for Issuers

[lmorchard]

What if, before the first badge is issued, a user could be guided by the Issuer to "Connect to Backpack"? (ie. stealing from the "Connect to Facebook" UX conventions)

This could combine with #131. That is, once a user has "connected" an Issuer to the Backpack, a trust relationship could be recorded and future badges could be pushed silently. This could also be an opportunity for the Backpack to introduce itself as a separate service, and offer some explanation for its benefits and how it's used.

Maybe this can be more of a UX and usage convention than an actual tech change, though. That is, convince all Issuers to award an initial freebie badge to prime the pump and call it "connecting", then use that first encounter to drive a Backpack intro experience and establish the trust relationship.

For background: In working through integrating Backpack with my issuing site, I've found a stumbling point in the need to sign-in to both my site and the Backpack. And, the latter most often happens within an iframe'd dialog that seems too well integrated into my Issuer site. (eg. "What do you mean I have to sign in again to get this badge? Aren't I already signed in? Is your site broken?")

[cmcavoy]

I think it makes sense from a workflow perspective, but I'm not sure it's light technically. I think we'd have to do an oauth like system so that it's easy to reject the issuer down the line. Good workflow, we should pursue it.

[lmorchard]

Yeah, I was trying to think about how something like this flow could be done without an true OAuth-style permission dance. The Issuer API is pretty convenient, being just a JS include. So, it would be nice if it stayed that lightweight on the Issuer end.

I think a tech-light approach to this would still require sign-in on both sides, stay with the iframe messaging, but make the UX more explicit about the process. "Connect" would really just be a special first-time intro UX for awarding the first badge from a given Issuer - and the "Connect" button would award that first badge right away, maybe even with a parameter explicitly enabling the first-time UX, if that's hard to detect automatically.

Also, rejecting issuers per #131 should be a matter of deleting trust relationships in the DB and refusing them in the future for an issuer (eg. with a blacklist table).

[lmorchard]

Actually, maybe what I'm thinking of is something like the intro experience at http://openbadges.org, but made more generic for all issuers. And rather than "get started >", there'd be a "Connect to Backpack" button on 3rd party Issuers.

[anyashy]

It might make sense to have the user "Connect" the backpack on the issuer's own log-in page. Personally, I like the "Connect" term because it distinguishes the action from any other log-in/sign-in process going on. Is it possible to replace the green "SignIn" BrowserID button with a "Connect" button (or really anything at all)? Also, is it possible to take the email the user used to log-in to the issuer's site and have it show up automatically in the BrowserID pop-ups?

[anyashy]

Maybe something like this for the workflow:

https://www.dropbox.com/s/robpvozdd8ua5h2/bp%20connect.pdf

[cmcavoy]

@iamjessklein do you have an opinion here? There's many UX possibilities to decide from.

[threeqube]

@brianloveswords brought up this use case in relation to the work ocupop is doing related to autopush of badges by approved issuers. We agreed having this is not in scope of v1.0. Updating milestone to v1.5.

[threeqube]

Correction, back in scope of v1.0.

[brianloveswords]

The major difficulty here is designing the connect flow so it doesn't rely on a specific backpack implementation. I'm working on something that's OAuth-inspired (but not exactly, since OAuth breaks down in a federated model) that I'll pass around for comments soon.

[toolness]

Doctor Brennan has been working on this: https://github.com/mozilla/openbadges/wiki/%5Bdraft%5D-Backpack-Connect. It's cool.

[lmorchard]

Huzzah!

[toolness]

Brian, your draft is cool, but I found this OAuth Dynamic Client Registration working draft recently and I'm wondering if it helps make OAuth more friendly to federated models. What do you think?

[brianloveswords]

@toolness I've just read that spec and I don't understand how it helps us. It increases the burden for backpack implementers because they now have to write logic for the registration endpoint in addition to the auth endpoint, and it increases burden for issuers because they have to make a POST request to register in the middle of the flow of trying to get an access token, then store their client_id and client_secret, and then immediately turn around and apply those credentials to the in-progress request to get an access token.

I just don't understand why having clients (issuers) preregister with a backpacks is such a good/necessary thing that we'd want to increase complexity across the board. @lmorchard, @cmcavoy any thoughts?

[toolness]

Ah, ok. I guess I just thought it would be cool if we could use existing standards rather than rolling our own.

Another option I'd considered was just using OAuth2 out-of-the-box, but with an assumed convention between issuers and backpacks whereby client identifiers are self-descriptive, kind of like a data URL. For instance, a client id that is the base64 encoded concatenation of the issuer's origin and callback URI. That would obviate the need for any kind of pre-registration, leaving things simple for issuers and backpacks (I think). It seemed reasonable given the intentionally vague description of registration in section 2 of rfc6749, but it could also be construed as a bizarre hack.

[brianloveswords]

Does the client_id even make sense out of the context of registration, though? Why does the authorization/resource server (backpack) care about a client_id if it isn't going to be matching it with a pre-known client_secret?

[toolness]

I guess it's partly just so it retains some semantic symmetry with the Oauth2 spec, and because (I assume) pre-existing OAuth2 tooling puts meaning on those things. Also whatever else is mentioned in the "When registering a client, the client developer SHALL" part of section 2... I'm still confused about whether client redirection URIs are supposed to be stored on the server as part of the client's configuration, or if they're supposed to be specified by the client as a callback parameter in a URL string, or if both are allowed.

Anyways, a lot of my proposal is more about minimizing the amount of work backpacks and issuers have to do. e.g. it would be great if both could just lift an OAuth2 package for their language and have it do most of the heavy lifting... but if there's not much that can be reused, the "standards hack" is probably more trouble than it's worth.

[brianloveswords]

@toolness Maybe it's worth checking out some existing OAuth2 provider/consumer libraries and see what assumptions they make.

I want to make sure we are defining our specification by the subset of OAuth2 that makes sense for the problem we're trying to solve. I'd rather not just say "use OAuth2" because that's a big implementation surface. However if we can say "we are using these parts of OAuth2" and there are already existing libraries that support our subset in the way we want to use it, that's a win.

[andrewhayward]

<advocate client="devil">Given that our situation involves not knowing endpoints until things are already happening, is there a reason why we're focussing on OAuth and not OpenID?</advocate>

[brianloveswords]

@andrewhayward OAuth is a spec for giving a site privileges to operate on a user's resources, which is exactly what we went. OpenID, as I understand it, is a spec for identifying/authenticating a user to a site, which is outside of the scope of what we're trying to do with backpack connect.

I'm not an OpenID expert, so please correct me if I'm wrong, but I don't see how OpenID solves the problem we're trying to tackle here.

[andrewhayward]

@brianloveswords Oh, I wasn't necessarily suggesting that it did solve the problem. I don't know a huge amount about either protocol, beyond implementation, but what I do know of OpenID (superficially at least) seems to fit our model better. Rather than having to pre-register with a service, you just stick your identity URL into a field, and both parties do what needs to be done.

OpenID Connect is seemingly the response to OAuth 2.0, though I don't know nearly enough about that to know if it's relevant either.

Anyway, was just a thought. Feel free to ignore!

[brianloveswords]

OpenID Connect is a suite of lightweight specifications that provide a framework for identity interactions via REST like APIs

I'll have to take a deeper look, but at first glance it's still about identity and not resource authorization.

[andrewhayward]

It's entirely possible that it's all irrelevant. Make of it what you will.

[toolness]

Hey, just to follow-up here, I followed what Brian suggested above, looked at node-oauth2-provider and noticed it didn't do a number of things we need (like refresh tokens). Furthermore, given the number of "hacks" we'd need to implement into OAuth2, I decided to go ahead and implement brian's draft spec. Progress is being made in #622.

[toolness]

The initial implementation of this is done and currently being hosted at our dev instance!!!! Woo!

We've also got Backpack Connect Issuer Documentation, too. With more API endpoints on the way, like #643. Also more UI tweaks.

:shipit: