Open to how it can be improved. What information do you think would be helpful? ( we may be too close to the situation to know what's missing )
On Tue, Sep 24, 2013 at 11:38 AM, Antonio Sanso <asa...@adobe.com> wrote: > Hi Chuck, > > On Sep 24, 2013, at 6:56 PM, Chuck Mortimore <cmortim...@salesforce.com> > 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 <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
