Hi Brian, thanks a lot for your pointer.
What the custom Google flow provides more than the oauth jwt bearer draft is IMHO an explicit way to build JWT without any 'human interaction' so a server can handle the construction of an expired JWT bearer token on his own. This can of course be figured out by any implementer (as the Google folks obviously did) but it would be nice to provide this black on white on a spec IMHO regards Antonio On Sep 24, 2013, at 2:35 PM, Brian Campbell <[email protected]> wrote: > Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what > you're looking for? > > > On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso <[email protected]> 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
