This is a Last Call for comments on
http://www.ietf.org/id/draft-ietf-oauth-v2-bearer-03.txt
Please have your comments in no later than March 25 (extended deadline because
of the ongoing OAuth base specification WGLC).
Do remember to send a note in if you have read the document and have no
I propose that the or native applications text be dropped from the
first paragraph in section 4.2 Implicit Grant [1].
There is clearly some disagreement about what is most appropriate for
mobile/native applications and many, including myself, don't feel that
the implicit grant works well to
Hello! Can some kind soul help me understand the purpose of the shared secret
part of the Temporary Credentials in RFC5849?
- The client authenticates using the Cient Credentials, and gets the Temporary
Credentials.
- The Resource Owner gives their authorization.
- The Temporary Credentials
Oops, just noticed a typo in my previous message, I meant:
The part that's puzzling me is the RFC says the client authenticates using
*both* the Client Credentials and the _Temporary_ Credentials in the Token
Credentials Request. I could understand one or the other, but why both? (and
Thanks for the quick response! Can I ask a more specific question: What's the
security purpose of the Temporary Credentials shared secret? If an
implementation were to, say, always use an empty string, would it make any
difference to the security of the protocol?
- Craig.
-Original
I agree with Tosten. A healthy client is not expected to issue an access token
request unconditionally when receiving an authorization code at its
redirect_uri. The client should do so only if it is in the right state with a
correlatable authorization request pending.
Best regards,
Huilan LU
It limits the ability to exchange the token in cases where the client has no
private secret, or if the client has multiple instances using the same
credentials (providing an isolation between them). You need to make your own
security analysis of the protocol and your needs.
EHL
From:
Comments on the bearer token spec:
1. There is a whole lot of text about OAuth2 get-a-token parts that isn't
necessary in the bearer token spec.
A bit of context can be useful to a reader, but in this case it brings too much
of the complexity of the get-a-token flows into what should be a
