Re: [OAUTH-WG] Separate HTTP and HTTPS tokens

Note that you could accomplish this functionality with the 'modify' proposal
I posted where an access token with a different scope could be requested
could be used to acquire a second token that has less privileges and would
be appropriate over HTTP.

To recap, 'modify' is like 'refresh' except the new scope is also passed as
a parameter.

-- Dick

On Thu, May 13, 2010 at 9:38 PM, Manger, James H <
James.H.Manger@team.telstra.com> wrote:

> David,
>
> > Why would we support bearer tokens over HTTP?
> > Is someone planning to implement this?
>
> Because the cookies-over-HTTP ~equivalent is widely used.
> The spec does say SHOULD NOT, but also explicitly talks about how to do it.
> the spec suggests limited scope and lifetime -- limited scope implies
> separate tokens for other scopes (eg for HTTPS).
>
> [section 5 Accessing a Protected Resource]
>
>   Access tokens SHOULD NOT be sent in the clear over an insecure channel.
>
>   However, when it is necessary to transmit bearer tokens in the clear
>   without a secure channel, authorization servers SHOULD issue access
>   tokens with limited scope and lifetime to reduce the potential risk
>   from a compromised access token.  Clients SHOULD request and utilize
>   an access token with a matching secret when making protected resource
>   requests over an insecure channel (e.g. an HTTP request without using
>   TLS/SSL).
>
>
> Even if you only support signed requests over HTTP you probably still want
> 2 tokens: a bearer token for HTTPS; a token+secret for HTTP.
>
> [
>  { "access_token":"Id87d6dDd", "sites":["https://api.example.org"] },
>   { "access_token":"SlAV32hkKG", "sites":["http://api.example.org"],
>        access_token_secret="386584633534" }
> ]
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>