2018-04-13 UTC
JanKusanagi, cwebber2, xmpp-social, vasilakisfil and evanp joined the channel
# 13:15 evanp aaronpk: I talked to sandro, looks like we'll get the namespace docs up
# 13:16 evanp aaronpk: and when you have a moment, I have another question for you
# 13:18 evanp Actually I guess I could just ask and you'll see it when you get beeped
# 13:20 evanp I realized it's @596 which is early in your longitude
# 13:26 evanp Sorry about that
# 13:26 evanp Round planet :shrug:
# 13:29 evanp For OAuth 1.0 I think there's a pattern where the server returns identity information with the access_token
# 13:29 evanp Like {"access_token": "...", "id": "https://twitter.com/evanpro"}
# 13:29 evanp Actually, I think Twitter does it the other way, providing a whoami endpoint
# 13:30 evanp I think the use case is that the end user provides an ID to the client, which is used to discover the OAuth endpoints...
# 13:31 evanp ...but they might make a mistake, or change their mind, and authenticate with another account
# 13:38 aaronpk But most OAuth APIs that don't do OIDC have a userinfo endpoint
# 13:39 aaronpk there isn't really a standard around it, people just do it
# 13:39 aaronpk that's also what IndieAuth solves, returning the "me" URL of the user who signed in along with the access token
# 13:41 aaronpk (IndieAuth also solves the problem of dynamic client registration by using DNS as the registration which helps in decentralized use cases like this)
# 13:56 puckipedia hmm yeah, I kinda hit the above issue while writing Kroeg v0, I hard-coded the user ID in the url and just assume that's the user ID you get back
# 13:56 puckipedia originally I made it so you can choose what actor to log in as, but that didn't work because I had no idea how to figure out who that was lol
jankusanagi_ joined the channel
# 14:36 evanp aaronpk: sorry, I drifted
# 14:37 evanp I'll take a look, thanks!
fr33domlover, evanp and githree joined the channel