On Sep 26, 2013, at 3:40 PM, Justin Richer <[email protected]> wrote:
> From what I read, it sounds like you want either the assertion flow > (which is defined in extensions) I do agree the assertion flow + JWT bearer token will suffice > or the client credentials flow not too sure about this though since it requires human interaction on input username/password regards antonio > (not the > resource owner password flow). In either of these, the client > authenticates on its own behalf and gets a token directly with no user > involved, and both are fully specified. > > -- Justin > > On 09/24/2013 08:08 AM, Antonio Sanso wrote: >> Hi *, >> >> apologis to be back to this argument :). >> >> Let me try to better explain one use case that IMHO would be really good to >> have in the OAuth specification family :) >> >> At the moment the only "OAuth standard" way I know to do OAuth server to >> server is to use [0] namely Resource Owner Password Credentials Grant. >> >> Let me tell I am not a big fun of this particular flow :) (but this is >> another story). >> >> An arguable better way to solve this scenario is to user (and why not to >> standardise :S?) the method used by Google (or a variant of it) see [1]. >> >> Couple of more things: >> >> - I do not know if Google would be interested to put some effort to >> standardise it (is anybody from Google lurking :) e.g.Tim Bray :D ) >> - I am not too familiar with IETF process. Would the OAuth WG take in >> consideration such proposal draft?? >> >> Thanks and regards >> >> Antonio >> >> [0] http://tools.ietf.org/html/rfc6749#section-4.3 >> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
