What you're describing is exactly what the JWT bearer flow specs out http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer
We've got the exact same flow, and there are other implementations out there. http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm On Tue, Sep 24, 2013 at 8:17 AM, Antonio Sanso <asa...@adobe.com> wrote: > Hi chuck, > > > On Sep 24, 2013, at 4:57 PM, Chuck Mortimore <cmortim...@salesforce.com> > wrote: > > I'm not sure I understand your point here. I don't believe there is > anything custom or special about the google implementation here vs JWT. > It looks identical to our implementation. > > Can you elaborate? > > > sure. > > What is novel IMHO in the Google approach is not the bearer format , that > is still JWT (or JWS in this case) but the overall scenario. > > As I see OAuth 2 is really good to cover use cases where there is human > interaction (so an user namely the resource owner can provider username and > password to the AS but not to the client and get back the Bearer Token). > This is obviously covered from [2] and [3] namely Authorization Code Grant > and Implicit grant flow. > > When there is not human interaction involved what RFC6749 offers is the > already cited Resource Owner Password Credentials Grant that IMHO is a no > go since it required the resource owner to share his password with the > client. > > The way as Google offers to solve the same situation (namely obtain , or > create in this case, a bearer token without having the resource owner > password) is using asymmetric cryptography. What is happening is that > quoting > > "During the creation of a Service Account, you will be prompted to > download a private key. Be sure to save this private key in a secure > location. After the Service Account has been created, you will also have > access to the client_id associated with the private key." > > An alternative mentioned from John Bradley previously is that clients can > securely generate key pairs but in terms of security would be identical. > > I hope is a bit clearer now :) > > regards > > antonio > > > [2] http://tools.ietf.org/html/rfc6749#section-4.1 > [3] http://tools.ietf.org/html/rfc6749#section-4.2 > > > - cmort > > On Sep 24, 2013, at 5:57 AM, Antonio Sanso <asa...@adobe.com> wrote: > > 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 <bcampb...@pingidentity.com> > 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 <asa...@adobe.com> 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
