I was going to bring up this point eventually, too. It seems backwards to me
that the client should be the only one to dictate what kind of token a flow is
for. I get the rationale -- the client knows better what secrets it can
resaonbly protect, right? But we've heard from plenty of people on the list
here that "oh, our servers are only going to use bearer tokens over ssl" or
"we're not going to use bearer tokens for anything". This is really a server
side (AS/PR) decision that so far is being made out-of-band.
I'm not sold on the token alteration quite yet though.
-- justin
________________________________________
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Mark Mcgloin
[mark.mcgl...@ie.ibm.com]
Sent: Tuesday, June 01, 2010 4:42 AM
To: Manger, James H
Cc: OAuth WG; oauth-boun...@ietf.org
Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2
It makes more sense to me to have the auth server dictate to the client
whether signing is required. The auth server could decide that based on who
the client is for example. What were the use cases or rationale for having
it the other way around?
If dictated by the server, then James suggestion for altering the token
response is a good suggestion
Mark McGloin
> On 31/05/2010 06:58 James Manger wrote
>>... we're going to have to split out profiles to deal with the
>> different key distribution challenges.
>Instead of starting with profiles, I think a key to addressing this issue
is to make the token response format richer. It should tell the client >app
all it needs to know to authenticate its calls to protected resources. From
a token response, a client app should know this particular services
>requirements: bearer token / client secret / token secret; shared secret /
public key; short-term / permanent; ....
>My mental model of the token response has it performing two tasks:
>1. Indicating how to authenticate requests to protected resources -- much
like a WWW-Authenticate response header for a "normal" authentication
>scheme (without user delegation).
>2. Provide all or some of the values necessary to make those authenticated
requests.
>The token response should include the name of the HTTP authentication
scheme that will be used to access protected resources.
>Example: { "scheme":"BASIC" ...} or {"scheme":"Token" ...}
>It makes it fairly obvious how to integrate other auth schemes with OAuth:
just include the parameters from that scheme’s WWW-Authenticate header >in
a token response.
>I quite like the idea of indicating whether subsequent requests are signed
with the client’s secret or a token secret by simply omitting or >including
such a secret in the token response.
>[This does assume that knowing the "scheme" is sufficient to determine if
a secret is required, which is one more reason why reusing "Token" for
>bearer, MAC and public-key operations is a poor design.]
>A (less desirable) alternative is a specific "client_auth":[TRUE|FALSE]
parameter in a token response.
--
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
