Re: Dialback authentication

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.
> 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>

I was working on the second problem, adding extra params to the 
protocol, and remembered Blaine mentioning that "we should have a more 
general mechanism for dialback", so I tried to capture it here.

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.
> 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.
I haven't convinced myself that a webfinger authentication is strictly 
necessary since it's bootstrapped by the host-meta anyway.

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.
>
> * 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/

> * 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.
> * 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.

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?

-Evan

-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net P: +1-514-554-3826