An interesting question is, who decides what kind of token to issue? 1)
Is it the authorization server because it knows what tokens and
signature algorithms are used by the targeted protected resource? 2) Or
is it the client? I would tend to #2 because I can imagine protected
resources with multiple endpoints (e.g. http and https) using different
token types. So it would be the task of the client to decide which way
is better suited for its use case.
I agree.
Authorization servers should issue credentials (tokens) with clear semantics.
If a token is to be used with a signature, its properties should reflect it. If
a server doesn't require signatures, why waste storage and bandwidth with
secrets.
EHL
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Brian Eaton
Sent: Thursday, March 25, 2010 8:50 PM
To: Ethan Jewett
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Thinking about our secrets for signatures
On Thu, Mar 25, 2010 at 7:54 PM, Ethan Jewett<[email protected]>
wrote:
Possibly this is a silly question, but why not #2 and have the bearer
token method (over SSL of course) include the token secret? The
provider would always issue a token and a token secret. If the client
is not interested in signing methods, it can discard the token and
keep the token secret. This secret is never sent in the clear using a
signing method. I believe that this is the approach taken in OAuth
1.0a and it seems like it should address this concern.
Well thought-out bearer tokens and well thought-out proof of possession
tokens rarely look the same.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
