- From: Martin Atkins <mart@degeneration.co.uk>
- Date: Wed, 29 Aug 2012 14:08:32 -0700
- To: Evan Prodromou <evan@status.net>
- CC: public-fedsocweb@w3.org
On 08/28/2012 07:52 AM, Evan Prodromou wrote: > Folks, > > We've talked before about mechanisms to authenticate HTTP requests using > dialback. > > I've written up a general method using the HTTP Authorization header, > similar to Basic or Digest authentication. > > http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/Dialback_authentication > > I'd appreciate your feedback here or on the talk page of the wiki. > I'm happy to see this avenue being explored. I think it's a nice compromise between strongly-coupled services and a free-for-all system, notwithstanding some implications for security. I apologize in advance for this potpourri of a message and am happy to discuss different parts of this separately if you prefer. ------------------------------------- In other forums before I've shared my earlier attempt at a similar idea: http://specs.mart.me.uk/dfp I would like to first draw attention to a difference in my design vs. yours and explain the reasons behind the decision. In practice I think the "best" solution (assuming that such a thing exists) lies somewhere in between our two designs. I made the dialback association step distinct from the request that is to be authenticated. This was for two reasons: * It allows the up-front cost of establishing the association to be amortized across potentially-many requests that follow, for the duration of validity of the bearer token. * It accommodates other mechanisms for establishing a domain association while using the same protocol for the authenticated requests themselves. For example, two domains with a pre-existing relationship may prefer to use a pre-shared secret for authentication in place of dialback. I'd concede that the latter of these can be handled by using different Authorization schemes if you accept a slightly different separation of concerns. The former I think is the bigger concern, and something touched on in your "Concerns" section. For a particularly "chatty" pair of domains (imagine, for an extreme example, Facebook sending notifications to Twitter) I think this optimization is important. Of course, the trade-off here is that the dialback request can't "see" the resource that's will subsequently requested and act based upon it. In effect that is mixing authentication (who is this caller?) with authorization (what is this caller allowed to do?) and I'd argue that the latter is better handled by the target resource itself rather than the dialback endpoint acting on the resource's behalf. ------------------------------------- With the domain association factored out into a separate step, I then assert for my proposal that a client that we know to represent example.com is then allowed to act as any user in that domain without having to do dialback for each user individually. This is why my proposal lacks an equivalent to your "Webfinger" mode, instead handling that by simply allowing the client to just name any user in the Authorization header. This is another optimization aimed at scalability: a domain can gain more users without having to scale up the number of dialback requests it has to deal with. Instead, associations scale by number of domains. (Of course, in an "indie web" scenario where each domain has exactly one user this is a moot point. I considered a one-user domain to be an edge case for my design, just as it is for XMPP and SMTP.) I think this speaks a little to your comment that you could combine "host" and "webfinger" into a different mode: you suggested that you'd have to be able to distinguish the two, but I'd argue that you don't and that "host" mode is the only one required on the dialback request. ------------------------------------- Other, smaller feedback not related to my proposal: * Perhaps an extra round-trip can be avoided by simply defining a /.well-known/dialback endpoint for doing dialback, rather than requiring host-meta. This is of course a trade-off that shifts if the same client will need other information in host-meta later and can thus fetch it once and cache it for many purposes. * I didn't quite follow what the "date" paramter is for. Is this in anticipation of the dialback endpoint checking that the date is sufficiently recent before returning in the affirmative? Why would this be a problem? * For an extra layer of assurance against DNS poisoning and similar attacks, you could advise or require clients to verify that the SSL cert matches for the given domain on the dialback request. This is of course still not a hard guarantee, but it can add an extra layer of complexity to an attack. (I weaseled around this in my proposal by mentioning it Security Considerations rather than in the normative prose.) ------------------------------------- I think that's all I have for now! Thanks for writing this up and sharing it.
Received on Wednesday, 29 August 2012 21:09:03 UTC