Thanks James.
I think overall your proposal is a good direction. I think the combination of
Link and WWW-Authenticate headers (static/dynamic) discovery is interesting.
If you have the time, I would love to see an I-D defining the OAuth2
authentication scheme (partial as you defined it) with cl
I don't think you are looking at it quite correctly. The token/auth code is a
session asserted by the server. The generated secret is asserted by the
client. This allows the server to detect more faults with the client or
attempts to intercept a particular sequence.
I'm not yet convinced it is
Torsten, that's what the spec recommends already. That's my assumption for
everything I've discussed thus far - that clients who can't keep secrets are
never issued them and thus must omit them out of lack of having any.
We're just splitting hairs on the definition of "omit." Also, there's
con
I can't see the purpose of "generated secret" by the client. I fear this is
going to lead down the same confusing path as the last thread on auth codes.
Essentially what you're asking for is a unique session ID per grant request.
If TLS is required across all connections to protect the generate
I am assuming the outbound requests are secured by TLS, but for various reasons
the return path (e.g. the redirect) might not be. Thus, one restriction would
be that the server never returns the code to the client.
Thus, you could submit a secret simply for the purpose of verifying the same
spe
This would be another possible standard option. As you pointed out, it would
help to detect authz code theft even for native apps. It would not help wrt
client authorization since there are no properties associated with the new
credential.
The key is: how does the authz server get to know this
Typo.
On Apr 8, 2011, at 8:04, "Andrew Arnott"
mailto:andrewarn...@gmail.com>> wrote:
Draft 15, section 2.1
Since requests to the authorization endpoint result in user
authentication and the transmission of clear-text credentials (in the
HTTP response), the authorization server MUST req
Why not have the client app generate a random text string to be used as a
request secret. The random text string would be matched during all subsequent
requests by the client surrounding a particular authorization. Assuming the
endpoints all require TLS for request side operations it would pre
As to the question of interoperability, the fact that OAuth allows freedom of
choice to the AS for method of authentication makes this point moot. Would you
agree? (short of various providers could pooling together to standardize on an
auth method outside of the spec).
One possible standard
Draft 15, section 2.1
Since requests to the authorization endpoint result in user
>authentication and the transmission of clear-text credentials (in the
>HTTP response), the authorization server MUST require the use of a
>transport-layer security mechanism when sending requests to the
I think I see the confusion now between this and Torsten's questions. The
assumption is that if the client has no secret, no assertion would be made. No
client authentication is performed. The app is essentially anonymous. That's
how folks interpret this?
So while I agree in theory, I propose t
[Sorry, I didn't see this email before I sent my last one]
> Chairs - I would like to ask that you declare all discovery requirements and
> use cases out of scope for v2 and the working group at this point.
>
> ---
>
> As for the error code registry and the request Mike posted, I do not thi
Yes, I can see how this might seem confusing. Actually, we're authenticating
the client with authorization server - not a resource request. On the MAC
threads we discussed how the token can be used for both. Hopefully that clears
everything up, but I'll briefly address some of the questions in
13 matches
Mail list logo
