Am 10.05.2010 00:25, schrieb Eran Hammer-Lahav:
3.2.1. Response Format
The authorization server MUST include the HTTP "Cache-Control"
response header field with a value of "no-store" in any response
containing tokens, secrets, or other sensitive information.
Would'nt it make sense to require "no-cache", too?
No idea.
I checked back with the rfc2616. I apparently misinterpreted the
semantics of the field and withdraw the question :-)
expires_in
Why is there information passed back about the access tokens duration but
not about the refresh tokens duration?
No one asked for that. Is there interest in specifying the authorization
duration in addition to the token duration?
Hmmm, is most people's assumption that refresh tokens never expire? Our
refresh tokens will expire.
And if an application is interested to know the duration of the access
token it will also consider the refresh tokens duration. Some people
will probably ignore both data and wait until the access/refresh token
gets rejected by the service/authorization server. So the error message
"authorization_expired" of the "refresh" request is much more important.
3.4. Client Credentials
The client credentials include a client identifier and
an OPTIONAL symmetric shared secret.
What is meant by "symmetric shared secret"? I'm familiar with the term
"symmetric" in the context of cryptographical algorithms only. I think "shared
secret" is sufficient.
Shared secret can be symmetric (password) or asymmetric (key pair).
Which secret is shared in the asymmetric case?
3.5. User-Agent Flow
These clients
cannot keep client secrets confidential and the authentication of the
client is based on the user-agent's same-origin policy.
Does this still hold in the context of "HTTP Origin Headers"
(http://www.petefreitag.com/item/702.cfm)?
BTW: Will Brian's security considerations document be updated to be in sync
with the draft?
Brian's document was written for WRAP. We need to write a full security review
for 2.0 that is structure similarly to OAuth 1.0.
---I copied the folliwing from other messages in this thread---
<Dick Hardt>
Besides changing some terminology, I would think Brian's doc would be
mainly reusable. Perhaps you could insert a version with changes you
understand, then people can suggest changes that need to be made.
<Eran Hammer-Lahav>
Since the security section is all non-normative language, it is the least
important part on my list. Brian's document is useful but is not something I can
work with>quickly. If someone wants to take a stab at converting it into a
section that can be cut-and-paste into the draft, I would be very happy to
incorporate it.
Is reformatting this document really sufficient?
I would like to assess the specification's security level from the
perspective of our usage scenarios. What I miss in the document is a
threat model of OAuth along with relations between possible threats and
respective countermeasures. So do I have to built this model on my own?
Or will there be a joint effort?
3.5.1.1. End-user Grants Authorization
I would suggest to use JSON encoding here, since the URI fragment is
handled by a client more or less like a response result.
3.6.1.1. End-user Grants Authorization
Why not call the "code" Parameter "verification_code"? It's called verification
code in the text.
Longer for no reason.
for the sake of clarity?
3.6.2. Client Requests Access Token
client_secret
REQUIRED if the client identifier has a matching secret. The
client secret as described in Section 3.4.
1) I'm having trouble to understand the meaning of "if the client identifier
has a matching secret". Is the assumption underneath that authorization
servers require this secrets from all clients they have issued a secret to?
What about client w/o a secret? Are they also allowed to use this flow?
Or is there envisioned a dependency
between the client type, clients credentials and the flows a particular client
is
authorized to use?
I would have expected a clear policy which flows require authentication and
which not.
Did you miss this question?
3.7.2. Client Requests Access Token
"authorization_declined"
Why does the spec interpret a request as bad request if the user just has
declined the authorization? According to rfc2616 the semantics of
400 is: "The request could not be understood by the server due to
malformed syntax".
The calling client did not sent a malformed request, it cannot foresee or
influence this outcome. I would suggest to either use status 403 or to return
status code 200 for all syntactically correct and authorized request and to use
another return codes in the response body to detail the requests outcome.
Did you miss this question?
4. Username and Password Flow
4.1. Client Requests Access Token
As statet in this section's introduction, this flow is intended to migrate
existing clients from BASIC/DIGEST to OAuth. I therefore would suggest to
use excactly these HTTP authentication schemes to transfer user credentials.
This would mean to remove the parameters "username"
and "password" and to use Authorization headers instead. At Deutsche
Telekom, we have to deal with that class of clients. Such clients have already
implemented their credential handling including header manipulation. The
proposed change would further simplify their migration.
How would you send both client credentials and user credentials? Migration is
only one example.
I withdraw this proposal. As I have written in my response to "Open
Issues: Group Survey": I would leave the end-user credential handling as
is in favour of using Authorization headers for client authentication
only. This will convey clarity.
6. Assertion Flow
This flow is suitable when the client is acting autonomously or on behalf of
the end-user (based on the content of the assertion used).
Let's assume the assertion attests an end-user's identity. How shall the
authorization server determine the clients identity in this case? I would
suggest to add optional client_id/client_secret parameters (or an
Authorization header) for that case.
That's the whole point - it doesn't need it because it uses a different trust
framework where the client identity is part of.
Could you please elaborate on the term trust framework? A SAML assertion
contains at most one identity but we need two of them. Where should the
second identity come from?
7. Refreshing an Access Token
I would suggest to add an optional "scope" parameter to this request.
This could be used to downgrade the scope associated with a token.
That would be the wrong way to do it given that people will expect to also be
able to upgrade scope.
What would be the right way?
8.1. The Authorization Request Header
I consider the name "Token" of the authentication schema much to generic.
That was also the feedback of all colleagues I talked to about the upcoming
standard. Why not call it "OAuth2"?
It is meant to be generic. I consider OAuth to be the part of the protocol
dealing with getting a token. There will be many new ways to get a token in the
future.
That's interesting! I consider the authentication scheme the major
contribution of OAuth since it allows for a standardized way of service
interaction. So 3rd party software components can be integrated into a
companies infrastructure (incl. AS) w/o customization. Moreover, as you
pointed out, there will be many other ways to get tokens in the future.
8.2.2. Form-Encoded Body Parameter
I would suggest to drop this section/feature.
General note: Would it make sense to add explicit format handling to the
OAuth API? If we envision authorization servers supporting more than one
token format (e.g. SAML, SWT, ...), the client should given the option to
request a certain format and responses returning access tokens should
indicate the format of this token. The OAuth authorization header could also
have an optional format attribute for the same purpose.
You mean token format? OAuth defined the token as opaque so that would be
counter-productive.
I dont't mean OAuth shall define token formats. I just ask for a way to
request tokens in a particular format and pass such meta data from AS to
resource server via the client. Why is that counter-productive?
Otherwise the resource server has to implement some token format discovery.
regards,
Torsten.
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
