2017-02-05 UTC
evanminto joined the channel
# 21:06 evanminto geppy: BTW, I did some more reading and I didn’t realize IndieAuth.com actually uses JWTs with the “me” value in the payload, so it IS possible to find the user’s token endpoint! # 21:07 aaronpk perhaps i should encrypt them so you can't accidentally parse them # 21:07 aaronpk you likely won't get parseable tokens from other peoples' authorization servers, so don't rely on that # 21:08 evanminto So I guess that means you can’t use IndieAuth tokens without providing the corresponding “me” value out of band? # 21:08 evanminto (Or having it be assumed, like in MicroPub) # 21:08 aaronpk it depends on which use case you're talking about # 21:09 evanminto I was exploring using IndieAuth tokens in ActivityPub # 21:09 evanminto But when the server sees the token, it has no way of knowing which user it’s supposed to be authenticating. # 21:10 aaronpk with micropub, the only server that gets these tokens is your own. but with activitypub you're sending the tokens to other servers. # 21:11 aaronpk this is the difference between authorization and authentication/identification # 21:11 evanminto I suppose you’re right. I guess IndieAuth is only doing authorization. # 21:11 evanminto I always get these mixed up :{ # 21:12 evanminto But it’s unable to authenticate the user for anybody but the user’s own site. # 21:17 aaronpk it sounds like what would be needed is to use openid connect with indieauth in order to get what it calls "ID tokens" # 21:22 aaronpk it's interesting how we sidestep this whole issue with webmention by having the receiver fetch the content from the sender rather than needing authenticated POST requests # 21:24 aaronpk evanminto: i had another thought, based on some previous brainstorming we had around private webmentions... # 21:25 aaronpk when someone is sending an activity via ActivityPub, presumably it's because they have an existing relationship with the receiver, correct? # 21:25 aaronpk (e.g. the receiver has previously "followed" the sender) # 21:33 evanminto Most of the time, but not necessarily # 21:33 evanminto Following is an activity too # 21:33 aaronpk what i'm getting at is at the point that relationship is established, the server that's going to later receive activities can issue an access token # 21:34 aaronpk so senders would be sending a different access token to each place they're delivering activities # 21:34 aaronpk that way receivers can implement whatever access token storage/generation/verification they want # 21:34 aaronpk e.g. if i'm receiving activities at my "inbox", I only have to worry about validating access tokens i've issued myself # 21:44 aaronpk that also has the benefit of not locking the whole ecosystem into a specific type of access token, which means the access token part is free to evolve as security requirements change over time # 21:44 evanminto That’s a pretty cool idea. # 21:45 evanminto Though it means federated and servers need to store a different token for each server. # 21:45 evanminto Maybe not the worst thing # 21:45 evanminto “Federated servers and clients” # 21:49 aaronpk haven't totally thought that through w.r.t activitypub yet, but there are a few interoperable implementations of that flow for private webmentions # 21:53 evanminto Oh yeah, that’s pretty interesting. # 21:53 evanminto I guess you could do something similar for a Follow activity # 21:54 aaronpk the "follow" activity essentially becomes the way that access token is established strugee joined the channel
evanminto geppy: BTW, I did some more reading and I didn’t realize IndieAuth.com actually uses JWTs with the “me” value in the payload, so it IS possible to find the user’s token endpoint!
aaronpk have you seen this? https://indieweb.org/obtaining-an-access-token