Hi, I'm Aaron Parecki

I want to share a little about what we've been doing in a related part of this space

and in particular, share about IndieAuth which is what like to call OAuth for the Open Web.

So I was part of the W3C Social Web Working Group which operated from 2014 until early this year.

We were chartered to develop APIs around specifically social networking applications, 

so to do things you would do on Twitter and Facebook but in an open web environment

and left out of the charter was specifically stuff around actual authentication mechanisms because that is a rabbit hole that you can get down quickly

so we were hoping to to focus on the API aspect of it.

We published several recommendations around small aspects of the space, so individual building blocks

things like letting comments go between websites, or ways for an app to post data to a server

and towards the end we also published some of the remaining work that was going on adjacent to these building blocks as W3C notes.

So what this has allowed us to do is build experiences on the web that work very similar to how you would use existing social networking applications.

This is an example of what I use every day now, which is how I read people online and talk to people on Twitter and talk to people on other social networking applications, their own websites or things like Mastodon.

and a lot of this is around specifically federation right, so I have that interface up at the top where I'm seeing something somebody wrote, I write a reply to them, I post it to my website and then they see it, it gets federated over to wherever they wrote the post and the comment appears there.

This is also what a lot of the work -- how Mastodon federates with other instances and other software.

So this is the space we're working in, I'm just giving this background to provide context for what I want to share about IndieAuth and OAuth.

So there's a couple of big challenges in the space which is essentially that because everybody is operating in their own environment in this, 

the question becomes how can I comment on this thing without having an account there?

How can I interact with this thing without a separate account?

People are trying to bring their own accounts into this ecosystem.

Also how can I sign into an app using an identity that I own?

And how can I sign into an app where I can then let that app post content back to my server?

So that is where -- this is also very similar to problems that OAuth has solved, but one of the main challenges that happened around the space with OAuth is that we basically got into this siloed environment, where everybody ends up building their own isolated systems of identities, and now an application that's trying to sign people in has to go and write code to consume each provider's identity separately. 

So you end up with these buttons all over the place where there's a whole row of buttons of 

"sign in with github" "sign in with twitter"

"sign in with eventbrite" and every app has to go an implement it over and over again.

So the idea with IndieAuth is to get back to this core idea of "bring your own identity"

I as the user want to provide my identity to an application in a way it can consume without writing specific code for my identity.

So the way this works is based on this idea that identities are URLs on the web.

And this is a very common pattern that exists in most web-based systems,

even if the user doesn't necessarily know it.

So for example with Twitter, you have a Twitter profile.

With Mastodon you have a URL that your profile lives on.

Even things like GitLab, which is the open source version of GitHub, user accounts exist at URLs.

You can also have people who actually run their own domain name as that URL, but it doesn't have to be that. 

You can have these sort of shared domains as well.

So the idea with IndieAuth is to take OAuth and take that mechanism 

which is a very solid mechanism built up over many years with a lot of implementation experience behind it and deployment experience behind it

take that, and then add enough to it that it works in this environment of existing on an open web where users can bring their own identity.

So we do a couple of things to accomplish that.

We take OAuth and then start constraining it. 

So we say user IDs are always URLs. Applications are identified by URLs as well.

So instead of having a client registration system, applications are just identified by the URL they are running at.

In order to find a user's authorization server, you start at their URL and ask their profile where to go to sign them in.

and then the user ID is returned at the end of the OAuth dance, similar to OpenID Connect which returns the ID information in a JSON Web Token. 

So this provides an experience that looks like this.

I'm on an application, in this case, Aperture,

I type in my URL, it is then able to find my authorization server and direct me to that.

This is what my authorization server looks like

which again is a very common pattern that you'll see in every OAuth application, 

"this application is trying to access this part of your account, do you allow access?"

If I approve that, I get redirected back to the application, it's able to finish the OAuth dance, get an access token and get my user ID back from the end of that dance, and then sign me in.

So this is actually implemented a whole bunch of places right now. 

If you have an account on micro.blog, every micro.blog account is also an IndieAuth URL.

The Known CMS, which is kind of like, similar to WordPress, but specifically for the micro blogging use case, also has native support.

If you're running WordPress or Drupal, you can install a plugin that enables this.

And there's a handful of open source projects that are sort of standalone versions of this OAuth provider that provides IndieAuth identities.

So this is the sort of summary workflow, I didn't want to go into the details of exactly the parameters that get passed. 

It's essentially -- if you're familiar with OAuth, it is the same mechanism, we've just added a few things to it.

So the idea is that you start out by prompting the user for their identity URL, and traditionally this is done with a login box where they type it in.

That obviously is not the best experience, I'm hoping we can solve that using other mechanisms like browser extensions that may be auto-filling it for you.

From that, the application discovers the authorization URL, which then the app goes and directs the user to that, which is exactly the same as the OAuth flow.

That's where the user sees the authorization prompt where they can allow access to that app.

The authorization server then issues a temporary authorization code, same as in OAuth, 

which the app can then go and exchange for an access token and the canonical user URL.

So that is the short version.

If you're interested in this, there are a couple links up here, and you can click them from the slides if you're in there.

So you can go find more reading, more details of the technical bits of it, how it works. 

and that's it, happy to answer questions.

>> Thank you Aaron, we have questions?

>> Hi this is Pamela, how does the client authentication piece of this work? If you have no pre-existing registration, how are you identifying yourself?

>> Yeah good question, so I sort of skipped over that, briefly mentioned it

which is that clients are all identified by a URL as well,

so in the OAuth world, the primary thing that client registration gives you is the ability to -- it does a couple things

it ensures that the thing that is exchanging the code is actually the same thing the code was issued to,

in a world where all clients are public clients, like JavaScript apps and mobile apps, you don't get a secret when you register, so you have to register a callback URL.

That URL basically acts as authentication already in the existing OAuth world and OpenID Connect,

so what we've done with IndieAuth is said that client IDs don't need to be pre-registered because the only thing it gives you is a way to put that information about the app there, 

so let's just use that URL to begin with.

So instead of pre-registration, registration is DNS.

So an application will be running at example.com, that's already an identifier that's unique in the system, 

so let's just use that as the identifier, and if we need to find out information about the app we can go and look it up at that URL.

>> Can anyone supply the URL as the client ID when they make the request?

>> Yeah, exactly, just like you can with public client in OAuth, find someone's client ID and supply that in the request.

So in OAuth we have this idea of public vs confidential clients, public clients being things that can't keep things secret, like native apps.

So we already can't use a secret when we're deployed in native apps in traditional OAuth,

so we're just taking the idea of public clients and doing all the protections that you would have to do with public clients and extending that to all clients.

Happy to go into more details of that later, cause it starts getting into the weeds pretty quickly.

>> Markus then Kaliya

>> Does this use Webfinger for discovery, and is not OpenID Connect, right, but is OAuth, which is talking about self-issued OpenID provider. Would that not work here?

>> So, this is solving a smaller scope of thing than OpenID Connect solves. So we are not trying to do anything around sort of session management or things like that. 

All we're answering is, is the person in front of the computer in control of the URL they claim to be in control of.

Not trying to then also establish session lifetimes or mechanisms beyond that.

OpenID Connect has all these additional claims that it can return, including the ability to use ID tokens as a session, things like that,

so totally different problem spaces in that sense.

Your question about WebFinger -- all the apps that exist right now ask the user to enter their full URL. 

That uses basically link rels, like HTML link rels, to find the stuff, so it's even less steps than WebFinger. 

If you wanted to have a user type in an email address to start out with, you would then need to use something like WebFinger to turn that into URL first.

We don't see a lot of that being done right now in the things that are running today.

>> Watching your presentation was like everything old is new again. So how is this any different than OpenID 1.0?

>> So that's a great question. OpenID 1.0 solved a lot of the same problems as this,

and then those problems kind of got push by the wayside when OpenID Connect came around.

So OpenID 1, the whole idea was bring your own identity.

It was *only* that aspect, it was only the "prove the identity" aspect.

So it didn't include anything around OAuth which is about the ability to get something that can be used to post data, to you know, access an API.

So OpenID only solved half of that first of all.

But the other thing that OpenID 1 -- so yes the original goals of OpenID 1 absolutely apply.

OpenID Connect kind of just said we don't care about those anymore, and we're going to switch into this world where enterprises issue identities and everybody is sort of siloed off and the issuer controls the identity.

Whereas it used to be like, I could log in to StackOverflow with my own OpenID and that just doesn't really exist in OpenID Connect anymore. 

I can't go to Google and type in -- bring my own OpenID and sign in to my Google account. 

So OpenID Connect went away from solving that original problem, which OpenID 1 did solve,

and then the second half of that being the OAuth aspect which is something that OpenID 1 never did, 

which is how does an app actually get an access token to access an API

and we wanted that aspect now as well.

And that's why OAuth provides a very solid foundation to build this on top of.

Thanks.

>> Thank you, Aaron

>> Thank you