Re: ActivityPump API

To be clear, I'm only suggesting that we start with server-to-server 
*associations* to start with. I agree that collective addressing is 
probably unnecessary; email has done okay without it, with 
intermediaries (listservs) doing the delivery fan-out as you say.

Now that I read over your proposal again, I think I understand it as 
creating an association for a domain instead of a user, in which case I 
retract my initial objection. I was confused the first time because the 
interaction between the dialback and the client registration wasn't clear.

However, it still feels like the "OpenID Connect Dynamic Client 
Registration" is a pretty heavyweight way to go from a one-off dialback 
to a "session" or "association". Not only is the protocol itself pretty 
intense (the fact that most parameters are optional notwithstanding), 
OAuth client credentials are traditionally long-lived and establishing 
this sort of relationship seems like overkill for just transmitting an 
activity or two between parties.

A shorter-lived bearer token can have much less management overhead on 
both sides: the issuer of the token can use cryptographic techniques to 
issue a self-sufficient token that requires no local state. and the 
recipient of the token can store it in only transient storage -- 
possibly even in per-process memory -- because a new token can be 
obtained trivially at any time.

I'll concede that you *could* implement the same strategy with oauth 
client credentials, using the "expires_at" parameter in the associate 
response, this is not how OAuth client credentials are normally used, 
and so this wouldn't really be a good compliment to an existing, 
more-traditional OAuth implementation.



On 10/16/2012 09:35 AM, Evan Prodromou wrote:
> I realize in theory inbox-per-server seems efficient; in practice it's
> an unnecessary early optimization. This is what PubSubHubbub does and
> it's the biggest problem with the protocol.
>
> The big problem with this method is that it requires the receiving
> server to understand and interpret collective addresses.
>
> For example, if I post an image to all my followers, or to people in my
> "Close family" list, or to people who've joined the "Ruby developers"
> group, the originating server can identify who should receive the image
> and deliver it to each person's inbox.
>
> Requiring a remote server to know who, if anyone, on its server is in my
> "Close family" list is unreasonable.
>
> -Evan
>
> Martin Atkins <mart@degeneration.co.uk> wrote:
>
>     On 10/16/2012 03:49 AM, Antonio Tapiador del Dujo wrote:
>
>         The last can be described using JSON AS + Audience Targeting +
>         Responses. I think that federation between sites could be
>         achieved with
>         only one activity point per site. This way, notifications to several
>         users in the same site could be delivered only once.
>         Authorization could
>         be handled in the similar way Facebook does with apps (note that
>         apps
>         are also authorized to publish on behalf of users if the
>         permission is
>         granted)
>
>
>
>     Yes, I think the best architectural approach is one that federates sites
>     (or domains, or other similar level of abstraction) rather than users,
>     because this scales better for sites that have many users.
>
>     While
>     the "indie social web" tends to have individual sites with one
>     user each, I think the "realistic social web" looks more like the email
>     network with most users on a few big providers. It would be great to
>     have a protocol that works well for both cases.
>
>     As I've noted before, this is the motivation for my design for the
>     "building block" Domain Federation Protocol[1], which I'd imagined being
>     the auth foundation for a protocol like ActivityPump. Personally I don't
>     see value in applying persistent OAuth client registration to this
>     problem, since associations between domains need only be transient in
>     most cases.
>
>     [1]http://martin.atkins.me.uk/domain-federation-protocol/
>     http://specs.mart.me.uk/dfp
>
>
>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Received on Tuesday, 16 October 2012 17:45:53 UTC