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
