- From: Martin Atkins <mart@degeneration.co.uk>
- Date: Tue, 04 Sep 2012 10:43:08 -0700
- To: public-fedsocweb@w3.org
On 09/04/2012 09:00 AM, Evan Prodromou wrote: > On 12-08-29 05:08 PM, Martin Atkins wrote: >> In other forums before I've shared my earlier attempt at a similar idea: >> http://specs.mart.me.uk/dfp > > Really sorry that I didn't reference this better. I had read the DFP > proposal, and although it wasn't at the top of my mind when writing this > dialback wiki page, it clearly has left its psychic residue, since there > are so many parallels. > No worries. I'm happy to see a different take on the idea, with different assumptions/tradeoffs. >> I made the dialback association step distinct from the request that is >> to be authenticated. > > I think this is a good idea /iff/ the protocol is standalone. My > intention with dialback is that it should bootstrap more permanent > relationships. > > Two important ones for me are: > > * PubSubHubbub subscription (so we can associate a subscription with a > Webfinger or host) > * OAuth client registration > <http://openid.net/specs/openid-connect-registration-1_0.html> My intent *almost* aligns with that; I was thinking of it as a *temporary*, ad-hoc relationship, assuming that in a truly decentralized world there may be entities you interact with once and then never talk to again. Of course, that's not to say you can't use the temporary ad-hoc relationship to establish a longer-term one: OAuth client registration seems like exactly that. > > Your Twitter-to-Facebook example works best if Twitter gets an OAuth > client id using client registration and Dialback authentication, then > uses OAuth authentication for all future calls. This sort of persistent association is handled in my proposal by the ability to obtain an association via a client id and secret obtained out of band, the implication being that in that case there is some business relationship (even if it's just a TOS clickthrough) between the two entities. I'd figured that service providers wouldn't want to do this without a TOS roadblock and so didn't design an automatic mechanism, letting the temporary association represent the ad-hoc case. >> 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. > > My weak dev-exp idea is that if it makes more sense for protocol to > think of a request coming from an account, then there's no reason not to > represent that, even if it's functionally equivalent. > > My weak technical idea is that "someone might want to" (four most > dangerous words in software!) designate a /different/ dialback server > than the default one for their account. But that seems so ludicrous I'm > ashamed I even brought it up. It's worth comparing this to SMTP and XMPP, which have a very similar architectural style: * SMTP doesn't provide a mechanism to override the MX for a particular user in a domain, only the domain as a whole. * XMPP connections represent a temporary association between two domains, and allow the servers representing those domains to act as any user from the domain without any further auth. I convinced myself this is the right design by reasoning that even if we did allow a per-user override, it would still be ultimately under the control of the domain "owner" and therefore they already have the ability to act as any user. >> >> * 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. > My read on RFC 5785 <http://tools.ietf.org/html/rfc5785#section-1.1> is > that having functional endpoints in /.well-known/ isn't in the spirit of > that definition. From the RFC: > > /well-known URIs are not intended for general information retrieval > or establishment of large URI namespaces on the Web. Rather, they > are designed to facilitate discovery of information on a site when > it isn't practical to use other mechanisms/ > Fair enough. I ended up making a similar determination in my proposal and created a /.well-known/federation endpoint... however, practically speaking there isn't much difference between an endpoint that returns a URL in its payload and an endpoint that returns a redirect to a URL, so you could define it such that the dialback endpoint is allowed to redirect. Not a big deal in the end, though. >> * 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? > > Rough idea being that nobody's obligated to keep a log of all requests > made for all time. If the "date" parameter is outside a certain window > (+/- 5 min, say) of the current time, it's OK to just give a 4xx response. I think I'd just let the implementer bake that into the validation token if they want. In practice I think you'd have to include the date in the validation token somehow anyway, or else you'd just be trusting the client not to lie to you. >> * 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.) > > Yes, using SSL on the dialback endpoint is a good SHOULD requirement. > > I assume you're not talking about client-side certs, which make the > whole thing unnecessary. No, certainly not. Just server certs as an extra level of protection. > I think the next step with the dialback proposal is to submit an > experimental internet draft; I wonder if you'd be interested in > co-authoring? > I think there are a few architectural details we'd need to resolve first, but sure, I'd like to help craft a draft. I'll also offer any prose/structure from my DFP proposal that you think is useful as a starting-point. https://github.com/apparentlymart/domain-federation-protocol-specs
Received on Tuesday, 4 September 2012 17:43:39 UTC