Phil phil.h...@oracle.com
On 2011-02-07, at 12:10 PM, Dirk Balfanz wrote: > > > On Mon, Feb 7, 2011 at 11:23 AM, Phillip Hunt <phil.h...@oracle.com> wrote: > What in oauth other than method of issue makes a token an oauth token? > > Is money obtained from an ATM suddenly ATM money? > > It would be if some vendors would only accept money which came out of ATMs. > Which is the situation we're in with OAuth. My analogy was more of the form that you can go anywhere in the world and use an ATM to obtain 'local currency'. All ATMs work more or less the same. The vendors around that ATM accept local currency. The same is true here. Tokens are issued for a particular security domain. The domain dictates the token types they want to use. Those tokens may turn out to be proprietary, or based entirely on another standard (e.g. Kerberos). > > > What if the tokens are Kerberos tokens. What makes them suddenly oauth tokens? > > What makes them OAuth tokens is that they came out of an OAuth flow. What > makes them OAuth token is that the resource server, upon receiving such a > token, will contact the local AS (not the kerberos server) and say "hey, I > received this OAuth token, can you please verify it for me". (If the AS > chooses to hand out kerberos tokens as OAuth tokens, that's its business). I don't see how the method of issue defines what something is. To do so implies that there must be a specification that defines an OAuth token. Method of verification and use of a token should be defined within the definition of the token. It sounds to me like people are after a universal token. Is that the case? I would prefer a scheme where the right type of token can be used for the job at hand. This means artifacts, bearer, MAC, etc can all be used. Even potentially Kerberos. It all depends on security requirements of the use case. > > Dirk. > > > Phil > > Sent from my phone. > > On 2011-02-07, at 10:39, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > >> Given the loose definition of tokens, any token issued as part of the OAuth >> flow is an OAuth token. It doesn’t mean that an OAuth token cannot be >> (internally or in practice) using a token format from another protocol. The >> idea that an OAuth token request may issue something other than an OAuth >> token is not compatible with the specification language, but this is just >> terminology and has little to no practical implications. >> >> >> EHL >> >> >> From: Phil Hunt [mailto:phil.h...@oracle.com] >> Sent: Monday, February 07, 2011 10:16 AM >> To: Eran Hammer-Lahav >> Cc: Dirk Balfanz; Manger, James H; OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) >> >> >> I don't agree that at token issued by an OAuth server is by definition an >> OAuth token. >> >> >> OAuth describes a flow pattern around how tokens may be obtained, etc. There >> are many types of tokens that could be employed. >> >> >> OAuth does not describe how SP's interpret and use tokens. It only suggests >> how tokens are presented. >> >> >> Phil >> >> phil.h...@oracle.com >> >> >> >> >> >> >> On 2011-02-07, at 9:54 AM, Eran Hammer-Lahav wrote: >> >> >> >> >> What don’t you agree with? >> >> >> EHL >> >> >> From: Phillip Hunt [mailto:phil.h...@oracle.com] >> Sent: Monday, February 07, 2011 8:29 AM >> To: Eran Hammer-Lahav >> Cc: Dirk Balfanz; Manger, James H; OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) >> >> >> -1 >> >> >> I don't agree fully here. >> >> Phil >> >> >> Sent from my phone. >> >> >> On 2011-02-07, at 0:02, Eran Hammer-Lahav <e...@hueniverse.com> wrote: >> >> Yes, any token issued via OAuth by an authorization server is an OAuth token >> by definition. Which makes ‘token_type=oauth2’ an silly and confusing >> statement, given that any token issued via this method is also an OAuth 2.0 >> token… but for some reason only one is labeled oauth2. >> >> >> EHL >> >> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >> Dirk Balfanz >> Sent: Sunday, February 06, 2011 11:16 PM >> To: Manger, James H >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) >> >> >> >> On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H >> <james.h.man...@team.telstra.com> wrote: >> >> Dirk said: >> >> > FWIW, I agree with Brian - it [the “Bearer” scheme] should say OAuth >> > somewhere, because it's an OAuth token. >> >> >> OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id, >> anything else. >> >> Conversely, any of these tokens can come from a variety of sources: a >> user-delegation OAuth flow, a client-only OAuth flow, a flow with nothing to >> do with OAuth, a device interaction, manual configuration…. >> >> Yes - they're all still all OAuth tokens, though. As opposed to passwords, >> basic auth tokens, etc., (which are also bearer tokens, but not OAuth >> tokens). >> >> A server receives a bearer token in a request. >> >> Dirk, are you saying the contents of the token (at that it is a bearer >> token) is not enough for the server? >> >> No - I'm sure the server can look at the token and figure out that it's on >> OAuth token. All I'm saying is that if it's an OAuth token, we should call >> it an OAuth token. >> >> >> Dirk. >> >> >> Does the server also need to know that it came from an OAuth flow? If so, I >> suspect the server actually needs to know more than that: such as which >> OAuth flow was used (eg user-delegation, client-only, assertion, future >> device flow etc), or from which authorization server it came. I don’t think >> a scheme name saying “OAuth” helps. >> >> >> -- >> >> James Manger >> >> >> >> _______________________________________________ >> 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
