Hi Chuck, On Sep 24, 2013, at 6:56 PM, Chuck Mortimore <[email protected]> wrote:
> 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 thanks this is indeed the same :) What it looks to me though is that the information contained in the second link you shared (http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm) are complementary to the jet bearer spec draft. People that will only read that spec would need to figure out all on their own . Is there any chance the oauth bearer draft will cover the actual use case as well or it would be too much ? Regards Antonio > > > On Tue, Sep 24, 2013 at 8:17 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
