hallettj_, tilgovi, KartikPrabhu and kbs joined the channel
#kbsWould someone here with webmentions implemented be able to give me a page that I can use for testing (likely filled with spam mentions)? I'm testing a rudimentary 'check-your-webmention-implementation-and-for-xss' sort of thing
#kbsso while it gets sorted out, probably will send a some testing mentions to that page :) so something that you can hide away etc would be awesome...
#aaronpkfunny thing is all the work that went into the oauth 2 spec is for exactly this purpose, although mostly people expected all the endpoints to be within the same company
#aaronpkthe spec is designed so that the auth server, token endpoint, and actual API share as little state as possible so that it can "scale" in an enterprise environment
#bearit's a hard problem to solve behind a firewall - and gets hairy with parts distributed
#aaronpkah yeah this is a little confusing because reasons
#aaronpkso if aaronparecki.com says its authorization endpoint is "https://indieauth.com/auth" then that is the *only* URL on indieauth.com that anything needs to care about
#aaronpkwhich means the user will be directed to indieauth.com making a GET request there, and the *same* route will be used to verify auth codes as a POST request
#aaronpkin this case, it returns a form-encoded reply
#emmakso i don't need to use indieauth.com/verify?
#aaronpkand you can ignore any previous docs about the /verify route since that's kind of a special case for the non-authorization version of indieauth
#aaronpk(eventually with the new indieauth sign-in service i'm making that will be unnecessary and i'll remove it from the docs)
#aaronpk(i'm literally working on that right now :)
#barnabywaltersthere’s a growing list of to-dos in GH issues I really need to take a chunk out of soon…
#snarfedkbs: after i added event rsvps to bridgy, a big event linked to the wiki and invited a bunch of people, and bridgy made loqi flood the channel with thousands of "invited" webmention notifs
#snarfedaaronpk: yup. the difficulty is that it'd be inside the e-content, and so most recipients would include it with the comment, which i don't want. moving it outside e-content requires nontrivial wordpress hacking, which i avoid a bit :/
#aaronpkkbs: do you know of a technique for arriving at a shared secret given two sets of public/private keys? (like diffie hellman but with keys)
#aaronpkoh I guess DH is usually implemented with public/private keys
#kbsaaronpk: looks like a neat idea :) have to look at it more carefully before too much blabbing. Vis-a-vis shared-secrets (in the context of PGP I assume) hm.. Usually people just encrypt with the other's public key (and possibly their own), as that serves the same functional purpose - but I have a feeling you're looking for some other purpose
gavinc joined the channel
#kbswould generally avoid using raw primitives - that tends to get into the domain of inventing a new security protocol, which is filled with here-be-dragons territory :)
#aaronpkkbs: I could accomplish prety much the same thing using PGP to encrypt then sign the message, or even just signing it and leaving it unencrypted
#aaronpkok cool. well oauth 2 dropped all the crypto stuff so it's way easier now, and also allows better separation of auth server, token endpoint and API which is where i'm going with this
#kbsaaronpk: *nod* oauth2 was a quantum reduction in suffering. I'm trying to come up to speed on your thinking about the indieauth end of it, will ping you again once I do that (or ask some naive questions, mor elikely :)
#aaronpkcool, would be great to have someone else to bounce ideas off of
#kbsI dunno if this might make any sense should there ever be a 'standard' android client, but that's way way off I suppose...
#kbsthe big take-away I really have is - don't use your personal google account on a rooted android phone :)
#kbsstops blabbing about android and gets back to work
#aaronpki should probably not read that until after I am at all familiar with the concept of the google play services library obtaining access tokens. i don't even know what that is for right now.
#snarfedkbs: great writeup! facebook actually does basically the same thing
#snarfede.g. our quip app asks the fb app for oauth authorization and a token instead of web
KevinMarks joined the channel
#kbssnarfed: oh interesting. The last time I looked (a year or so back) it was a bit less overt (ie, the scope-grant logic was still controlled by the server, not pushed into the client)
#snarfedoh fair point, that part may still be true
#kbsyea. I think the interesting thing g+ does is mostly that the scope logic is no longer on the server (for all practical purposes) - the client directly decides on what scope to grant, and it has the ability to give anything...
#kbsah, finally got the irc logs too - let me read that first as well...
#kbsto ask the first (of many no doubt!) baby questions - by 'token endpoint' - does that mean an OAuth2 provider? Ie, the desire to behave like an OAuth2 provider for a client that wants to publish something on an indieweb site?
#aaronpk"OAuth 2 provider" is kind of a broad term that is not very useful
#aaronpkoauth 2 splits things up into the authorization endpoint, the token endpoint, and the resource server
#KevinMarks_I was trying to make noterlive a micropub client, then I broke it completely. I really should go fix that
#aaronpkan "OAuth 2 provider" probably includes all three of those things
#kbsokay, I see - you want indieauth to specifically be in just the token endpoint piece of it
#aaronpkindieauth.com is actually just the authorization endpoint
LauraJ joined the channel
#aaronpkcurrently you need to build your own token endpoint that issues access tokens (although I'm figuring out the best way to create that as a service too)
#kbsbtw - the oauth client flow on android at least is horribly broken security-wise
#KevinMarks_"OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations."
#aaronpkthat said, it is entirely possible to have a bearer token that happens to be an encrypted string. but that's only important to the things issuing and verifying the tokens, not the things using them
#KevinMarks_that was part of the oauth2 debate, iirc.
#kbsso at some stage (I think, esp for mobile-apps) they have to verify their app-identity reliably - fwiw, android has gone down the route of using their pubkey signatures as providing this proof. It happens to be implicit on android, simply because the platform was set up this way...
#aaronpkah yeah, that's kind of a problem with mobile apps in general right now
#kbsKevinMarks_: yea - it was pretty fun to see how they cracked that particular issue on android
#KevinMarks_aaronpk, have you considered coming to IIW?
legastero joined the channel
#KevinMarks_benwerd and I will be going, and intend to pitch indieweb and indieauth
#aaronpkI would more say that authentication should not be tied to micropub, so it should be possible to keep the core of micropub and swap out the auth part if needed later
#aaronpkand for now, use the most common parts of OAuth 2 since that's what we've got
#kbsso you're thinking of using (in effect) bearer tokens to communicate signed statements of granted privileges between the three endpoints in question?
#kbsso in my state of confusion, I interpret the box "authorization server" in the rfc as performing the task done by your box that says "token endpoint" what important thing am I missing? :)
#KevinMarks_aaronpk: if I want to post a long article, will form encoding cope?
#kbsI think the distinctions between "authentication" and "authorization" are a bit fuzzy to me right now (in terms of its intended semantics in various contexts, I mean) -- continuing to try and grok this...
#aaronpkkbs: the rfc's 'authorization server' should be the same as mine :)
#aaronpkalthough in my diagram it's labeled 'authorization endpoint'
#kbsyep - there's some terminology confusion between 6750 and 6749, and you're using 6749 I assume. In rfc6750 A/B corresponds to your diagram's "authorization server", and the C/D steps correspond to your diagram's "token endpoint". rfc6750 calls the first "resource owner" and the second "authorization server" :)
#aaronpkyeah the bearer token doc (6750) is lumping everythign together into an "Authorization Server" rather than explicitly talking about the two endpoints
#kbsso I think I begin to get what 6750 wants to do, in terms of being modular between the authorization and token-access steps (ie, the A/B vs the C/D)
#aaronpki'm writing up a simpler version on the brainstorming page
#kbsaaronpk: thanks - makes sense. I think the confusion (such as it is) is that the nomenclature within the rfc is confusing - probably because it subconsciously wants to both those endpoints within an 'authorization server'
#kbsso to a first approximation, I *think* your idea is that the authorization-endpoint to return a token that asserts: [app=someid, user=someid]-signed-by-authorization-endpoint. This is passed to the token-end-point, which then returns [user=someid, scope=this-permission]-signed-by-token-end-point. Both are finally passed to the micropub endpoint, which can decide whether to honor these assertions
#kbsthe 'mandating' part of it essentially would be the format of these assertions, (perhaps JWT)
#kbsso I think I'm finally somewhat vaguely in the same county as your ideas and thoughts on this, sorry took so long :) still digesting ideas to a large extent
#kbsthe one practical thought that strikes me, is that underneath all this is still just two things, which is proving that a user foo is really foo, and that client-app-bar is really client-app-bar - things that are to some extent "put-under-the-rug" by the authorization endpoint
#aaronpkassuming we do pass around JWT tokens, the question is what value is used to sign them
#kbsso if I were to put on my pgp hat (which has sadly skewed my thinking too much) there would be well-known endpoints for locating public keys of the user/site, app, and the endpoint services. Something analagous to grabbing it from rel=key links of the user's site
#aaronpkwell it just so happens that every ID here is also a URL that is assumed to have HTML on it, which means a public key could be discoverable that way
#snarfedyeah, i think i checked a while back and you could do that to
#KevinMarks_I think you cna add some html, but it sanitizes fiercely, so check
#kylewmso I sent a pingback from my wordpress.com blog to my real site, and it has a u-in-reply-to but it doesn’t do anything because there’s no h-entry
#aaronpke.g. "The token endpoint verifies the authorization code"
#kbsaaronpk: *nod* I _think_ I get the drift of where you're headed with passing signed assertions as tokens. There's a bit of trickiness with validating public keys themselves, but that's a whole 'nother can of worms
#snarfedkylewm, KevinMarks: yup, i haven't done much (anything) on the sending side yet. needs research
#kylewmnot sure you need to… wp.com sends pingbacks, and webmention.io can proxy them into webmentions
#snarfedaha, that's nice. i wonder if blogger and tumblr do too
#snarfedi was planning to use superfeedr, which will hit a webhook when new posts are created/updated (and send the content w/useful metadata). much easier than polling. but webmention.io sounds great if it will work
#snarfedaaronpk: not sure i follow. it looks like webmention.io lets you translate incoming pingbacks to webmentions, ie you advertise w.io as your pingback endpoint and it will send them to you as webmentions
#kbsaaronpk: one heads-up is that I think you might need a separate little dance to prove that some app talking to you is really using a specific client-app's pubkey.
#snarfedright, ok. i misunderstood kylewm. so kylewm, sounds like you meant, since wp.com sends pingbacks, other sites can accept them if they use webmention.io's proxy
#aaronpkkbs: so one of the criticisms of OAuth 2 is that it doesn't actually do any sort of client verification because all you need is a bearer token, and bearer tokens can be shared around all day long if you want
#snarfedkylewm: ok. sounds like they'd be complementary. i'd like wp.com (etc) blogs to be able to send normal webmentions too, so recipients get them even if they don't use the proxy
#kbsaaronpk: more about something before bearer tokens are even issued I guess. So as an authorization endpoint, I get a call that says client_id=https://ownyourgram.com - how can I tell that it's really the ownyourgram client calling me, and not someone else.
#kbsI wonder how it might work for mobile-app clients?
#aaronpkverifying redirect URIs on mobile clients is not really possible right now, cause any app can register the "facebook://" scheme unless the facebok app is installed
#KevinMarks_that's a good way to avoid pre-registering the callback URL
grantmacken joined the channel
#aaronpkKevinMarks_: exactly! avoiding pre-registration is a goal here
caseorga_ joined the channel
#KevinMarks_on android, you'd get to choose. On iOS you can install an app witht hat scheme and behavior is undefined
#snarfedkylewm: plenty of work on this left to do, lmk if you're interested!
#kbsbut I did like the android approach of leveraging the code-signature to authenticate client apps, if there's something similar for ios it might be one random thought
#kbswhen I make such a request, I can pick up the signature of the calling app, which then becomes a clear way to identify the app that's makeing the request
#kbsof course - this relies on there being such a 'trusted' app - which would (conceptually) be similar to relying on indieauth.com as a trusted service
#aaronpkespecially cause worst case we are in no worse a situation than every other ios app right now
#kbs*nod* I've been mostly in too deep in mobile/android apps for a bit
#kbshence rather too skewed to looking at it in that context
#kbsHaving the app url register callbacks at a well-known location is a cool idea - neatly sidesteps a lot of the awkwardness
caseorganic joined the channel
#aaronpkyep and if a mobile app also publishes its redirect URI on its *web* home page then at least there's that
fmarier, legastero and j12t joined the channel
#kbsKevinMarks_: sorry, late response to webview question - wasn't thinking about that (and I have a whole 'nother rant about apps that use webview to do OAuth on android, but never mind :)
#KevinMarks_though that only works for OAuth to google endpoints, right?
#kbsyep. But, I really like that google has made it possible to use web-tokens to enable that for non-google endpoints. Tim Bray wrote about this a while back, it's nifty
#aaronpkany sort of oauth with an embedded web view is not safe
#kbsit still ties in to some degree with google (ie, a google account gets used) but it lets additional endpoints be reliably (== also client-app verified) accessed
#kbsIt basically exposes the same trick (ie, using the play-services app as the 'trusted' app that pulls out the calling app's signature) to mediate access to other endpoints
#kbswell. Added one test case :) I'll add some more and stick things on github as well - so anyone can continue adding tests. https://checkmention.appspot.com
#KevinMarks_aaronpk was just saying how natural using fragmentions is now
brianloveswords joined the channel
#aaronpkso I think I'm going to write up a doc saying "if you are making an auth server, then generate your auth codes like this using JWT so that they can be verified out of band"
#aaronpkand then also suggest that both the auth endpoint and token endpoint be an API for verifying their own tokens so people have the option of checking the JWT or just using an API cause that's easier
#kbssnarfed: if you're awake - there's one (1) test on https://checkmention.appspot.com - :) please do let me know about better copy, etc. It was cooked in the throes of insomnia last night, so probably have done a bunch of things screwy.
#snarfedbtw kbs feel free to run new tests on my site yourself. (i know it's nice to have test cases.) i'll see them come in, so i can clean them up later
#kbssnarfed: ah, great - thank you much. Is there a particular page I could use? One of the urls you've already used?