David
Although you stated you were taking WRAP and adding signatures, I found many
other differences between the specs. I'm baffled at why you essentially started
from scratch on this document rather than taking WRAP and adding the device
profile and signatures.
Per your previous email:
My goal by removing some of the non-obvious things was to encourage
the discussion which has now started
Here are numerous discussion points on your draft. I look forward to a response
on each one.
-- Dick
1.2.1 The security and risk profile of a JavaScript or other RIA is different
from a Rich App. The user can easily be fooled to run a RIA, but in general
must be actively involved installed a Rich App. A RIA has an identity mechanism
(URL it came from). Combining these makes it tougher to analyse the security
issues and requires prohibits taking advantage of one context.
1.2.3 Google has been using captchas in their flows for some time. I'd like to
hear from Google and others that have deployed captchas here that they do NOT
want it as an option before it is removed.
1.2.4 I think this is a security consideration, not a specification MUST. Many
use cases are fine moving cookies in the clear where the cookie.
1.2.5 All refresh token requests are not the same. I see that I mistakenly
dropped a feature in draft-hardt-oauth-01. In 5.4.8 of WRAP 0.9.7.1 the refresh
request also includes the client identifier and client secret. This enables a
catastrophic loss of refresh tokens at a PR to be recovered by changing the
client secret and not requiring the client to have to reacquire authorization
from the user.
1.2.6 How is an AS supposed to mark an Access Token as no longer being valid?
Are you implying that there is a Access Token revocation mechanism? I did not
see where the spec discusses the invalidation of an Access Token. Did I miss it
somewhere?
Other changes from WRAP that were not highlighted.
A) The User Delegation profiles were put in a separate section from the
autonomous client flows to highlight to readers the difference in the flows.
Your draft merges them which could be confusing. It was often confusing to
readers of WRAP previously.
B) Change from using profile to flow. Personally I think flow is better. Would
be interested to hear others thoughts.
C) Placement of Acquiring an Access Token prior to Accessing a Protected
Resource. Most new readers will be Client or PR developers. What they care
about is accessing a PR. Once they see that they need an Access Token to access
a PR, they then understand they need to get an Access Token. They then can jump
to the profile/flow that is relevant for them.
(D) The Parameter Considerations section was removed. We had found this section
useful to collect common information about parameters.
1.3 Terminology
1.3 access token: why is this a now a unique identifier? the deployed usage of
Access Tokens in WRAP is that this is a token, not an identifier. This was a
significant feature in WRAP, that the Access Tokens are claims, not
identifiers. This is also why the Access Token size could be larger.
1.3 client: what do you mean by "OAuth-authenticated request"?
1.3 refresh token:. why does the refresh token need to be unique? can the AS
hand the same one out to a client later on or does it need to track which ones
it has handed out?
1.3 server: Why is server defined when we have protected resource? I don't
understand the difference.
1.3.1 Why is this a subsection of Terminology? I find the use of the term
server here very confusing. Is the PR a different machine? The Authorization
Server? Why does the client discover them from the server?
1.3.1 255 character Access Token length recommendation. This was a joke right?
There was a discussion of this on the list and no one was agreeing with
Facebook reps on limiting the Access Token. Since it is a recommendation,
people can go over, so what is the point? The real limit is what can be
included in HTTP headers or in a query string, not the size of a MySQL record.
1.3.1 URL safe characters. What is the basis for this requirement? Many
existing systems will likely have other non URL safe chars in their existing
Access Tokens. You are now creating Microsoft's deployed Simple Web Tokens
that are used in WRAP are not URL safe.
1.3.1 Why is the Access Token length and character set in a section entitled
Endpoints? Why did you drop Parameter Considerations? That section would have
been the logical place to have included information such as this.
2 "five core flows" ... this implies any other flow is inferior. Why are they
core? Per comment above, in WRAP we found it useful to separate the user
delegation flows from the autonmous client flows.
2 "Common scenarios involve the resource owner delegating to a client to act on
their behalf, adding another party (the resource owner) to the protocol."
Which protocol is the resource owner being added to?
"Unlike the others, Client Identifier and Secret flow (Client Identifier and
Secret Flow) is intended for a client acting on behalf of itself and not a
separate resource owner. For example, when a client is accessing non-private
data or modifying data about itself." This is a much narrower use case than
what motivated the Client Account and Password Profile.
draft-hardt-oauth-wrap-01 5.1 was motivated for autonomous clients calling an
API. The data is likely private and not about itself.
2.1 In contrast to 1.3.1 where the endpoint is obtained from the server, now
the client obtains it from the authorization server. Which is it?
2.1 there are a number of steps here. Would be useful to break into separate
sections similar to draft-hardt-oauth-wrap-01 to guide discussion.
2.1 are there any checks the AS needs to do wrt. the initial request such as
check the callback URL?
2.1 "The way in which the server handles the user authorization request (such
as via cookies), including whether it uses a secure channel such as TLS/SSL is
beyond the scope of this specification. However, the server MUST first verify
the identity of the resource owner. If the resource owner approves the
authorization request, the authorization server MUST generate a verification
code and associate it with the client identifier and callback URI. "
Why MUST the AS generate a verification code? I would hope the AS would also do
some checking on the parameters from the client such as matching the client
identifier with the callback URL.
2.1 "If the request is authorized, the access token is included in the HTTP
response body using the "application/x-www-form-urlencoded" content type as
defined by [W3C.REC‑html40‑19980424] (Ragget, D., Ed., Le Hors, A., Ed., and I.
Jacobs, Ed., “HTML 4.0 Specification,” .) with a 200 status code (OK)."
What steps does the AS do to authorize the request?
2.1 "The authorization server must retain the scope, duration, and other
attributes approved by the resource owner, and enforce these restrictions when
receiving a client request made with the tokens issued."
What is this sentence doing in this section? How is the AS to enforce these
restrictions? Why is the client making requests to the authorization server?
2.1 "oauth_error_reason
Value must be one of "callback_url_mismatch" or "expired_verification_code"
(case sensitive)."
What if it is a different error such as invalid client secret or client
identifier? What if the oauth_mode is not supported?
2.1 HTTP/1.1 401 Authorization Required
WWW-Authenticate: OAuth realm="example"
oauth_error_reason=expired_verification_code
Where did the WWW-Authenticate header suddenly come from? Where do these values
of realm come from? This is an example, but I don't see where including this
header was specified.
2.2 As mentioned above, the security considerations for a RIA and Rich App are
not the same.
2.2 Once again, this is a long section and breaking it up into steps would make
it easier to refer to a step.
Why does a Rich App now have to have a callback URL? How does the Rich App get
the verification code? draft-hardt-oauth-wrap-01 captured a number of best
practices for how a Rich App can get the verification code.
2.3 oauth_verification_rate_limit: What is an AS supposed to do if a Client
calls more often?
2.4 "This flow is used when the authorization server generally trusts the
client to temporarily collect the end-user's username and password and it is
impossible to use one of the other authorization flows." what determines
"generally trust" from other trust situations?
2.4 "The authorization server MUST verify that the resource owner's credentials
are accurate and MAY verify that the client is authorized to use this flow."
Why is verifying the client is authorized to use this flow a MAY rather than
MUST?
2.5 Why was this renamed to Client Identifier and Secret Flow? In
draft-hardt-oauth-wrap-01 we specifically called it an Account Name and
Password flow to avoid confusion with how client identifier and client secret
are used in other parts of the protocol. As noted in the introduction above,
this is a common use case. It seems that the terms secret and password are
being used interchangeably, which is confusing.
3. See 1.2.5 for why it makes sense to have different refresh flows
3. Having a new parameter to get a secret looks like a hack. We have the
oauth_mode parameter, make it another mode.
3. How is the AS supposed to know which PR the client is going to talk to? How
does it know what signature methods are supported by the PR?
4.1.1 why does is the parameter name oauth_access_token rather than just
access_token? It is in the context of an OAuth authentication.
4.1.1. "The protected resource MAY include further details about why the
request was rejected in the response body or headers." this sounds like a
vague way of providing additional error information. Seems it would make sense
to standardize best practices here.
4.2 Why does the client not sign requests to the AS if it has a client secret
to sign requests with? Signing is much better than including a secret in a call.
4.2 Why refer to [draft‑hammer‑oauth‑10] (Hammer-Lahav, E., Ed., “The OAuth 1.0
Protocol,” for the computing the signature string. Could you not copy that
text over here? Are you anticipating there will be a separate spec for
computing the signature?
4.2.1.1 Lots of TODOs here. I thought that OAuth 1.0A had this all figured out.
Why are there TODOs???
Examples??? Where are the examples??? Do you not plan to have examples? Is it
coming? WRAP had a couple of good examples IMHO. Not sure why you would not
want to use those.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
