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
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
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
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 :/
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
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 :)
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.
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)
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...
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?
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)
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
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...
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
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? :)
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...
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)
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
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
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
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
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
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.
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
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
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 :)
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
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
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