I, for one, support replacing the hand-rolled token stuff with "OAuth 2"; it probably makes the spec a tiny bit more complicated to implement in practice, but in theory (i.e., the long run) it probably makes it easier, and certainly future-proofs things, at least compared to the current PuSH spec.
b. On Jun 16, 9:16 pm, Justin Richer <[email protected]> wrote: > The PuSHEE project is getting to the point of us building in an > authentication and authorization layer to the system, and we're planning > to build this around OAuth2. I would like to gather comments from the > PuSH community in how to move this forward. I saw an initial draft on > adding in OAuth support and a content-agnostic discovery mechanism, and > we'd like to help move both of these forward, since they're both > problems that we need to solve. > > We're looking at several authentication points: > > * Client to hub: is this client allowed to read this feed? > * Feed to hub: Is this hub allowed to ping this hub? > * Hub to feed: Is this hub allowed to broadcast this feed? > > The first two are fairly easy, but the third gets tricky, and we're > looking at using JWT formatted OAuth tokens to allow for easy remote > checking on feed publisher's side, or by implementing the proposed OAuth > token check endpoint that's being passed around. > > How many of these can replace existing auth checks in the PuSH spec, > like the hub reply nonce and secrets? Seems like we might be able to > move some of this into a profile of OAuth instead of something built > just for PuSH. This is to say nothing of the signing mechanism, which > could use EHL's OAuth2 MAC proposal or Magic Signatures. > > We're also looking at building an API for registering feeds to a hub > which would require auth as well. The question here is whether this > ought to be rolled into PuSH or just stand as a separate PuSHEE API. > > -- Justin
