On Sep 24, 2013, at 5:22 PM, Bill Mills <[email protected]> wrote:
> So they are using client authentication as defined on OAuth 2 then? good point indeed :) My main point is that all the pieces of the puzzle to solve this scenario are probably there beetwen the OAuth core the JWT and the JWT bearer token specifications but it would be tough to an OAuth newbie to figure out all this on his own…. regards antonio > > > On Tuesday, September 24, 2013 8:18 AM, Antonio Sanso <[email protected]> > wrote: > Hi chuck, > > > On Sep 24, 2013, at 4:57 PM, Chuck Mortimore <[email protected]> > 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 <[email protected]> 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 <[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 > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
