On Mon, Feb 7, 2011 at 11:23 AM, Phillip Hunt <[email protected]> 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. > > 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). Dirk. > > Phil > > Sent from my phone. > > On 2011-02-07, at 10:39, Eran Hammer-Lahav <[email protected]> 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:[email protected]] > *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 > > <[email protected]>[email protected] > > > > > > > > On 2011-02-07, at 9:54 AM, Eran Hammer-Lahav wrote: > > > > What don’t you agree with? > > > > EHL > > > > *From:* Phillip Hunt [mailto:[email protected]] > *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 < <[email protected]> > [email protected]> 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:* <[email protected]>[email protected] [mailto: > [email protected]] *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 > <<[email protected]> > [email protected]> 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 > <[email protected]>[email protected] > <https://www.ietf.org/mailman/listinfo/oauth> > https://www.ietf.org/mailman/listinfo/oauth > > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
