Sorry for the late comment on this, Eran. I like your idea, but would
suggest that better than company name would be domain name or based on
domain name (I don't recall if '.' is allowed in this context). Company
names are by no means unique, and even within a large company one could
envision
Can we not acknowledge in the abstract that there are other applications
for OAuth beyond the delegated authz scenario?
I tell people that OAuth 2 is more a framework than a specific protocol,
but the current abstract belies this claim.
paul
On 4/5/11 8:57 PM, Mike Jones wrote:
Also,
Hi Eliot,
Prefixing query parameter names with a full domain is not likely to be an
acceptable style. For example, Facebook uses fb_ as their prefix (most of the
time) but my guess is not likely to go with fb.com.param or fb.com_param, not
to mention facebook.com.param.
I think the consensus
Can you propose text?
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Paul
Madsen
Sent: Wednesday, April 06, 2011 4:00 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-15 editorials
Can we not acknowledge in the abstract that there are other applications for
New text:
Extension error codes MUST be registered (following the procedures in
xref target='error-registry' /) if the extension they are used in
conjunction with is
a registered access token type, a registered endpoint parameter, or
an extension grant
Proposed text
The OAuth 2.0 authorization protocol enables a third-party applicationto
obtain limited access to an HTTP service, either on behalf of an
end-user by orchestrating an approval interaction between the end-user
and the HTTP service, or by allowing the third-party application to
Hi Mike,
This is intentional. The error registry defined in v2 is not designed to record
errors for the protected resource endpoint response or the WWW-Authenticate
response header when used with the Bearer token scheme (or any other scheme).
The only purpose of the registry is to avoid name
The problem with that situation is that it doesn't provide a central registry
for resource server error responses across specs, unlike the other kinds of
OAuth error responses. I could define that registry in the bearer token spec,
but it would be less confusing to unify it with the proposed
Putting aside my view that a registry for resource server error responses
across HTTP authentication schemes isn't very useful or interesting, I don't
have an objection to the bearer token specification defining such general
purpose registry. In a way, it is similar to the error response
Actually, you correctly point out (indirectly), that this is related to one of
the open issues that needs to be resolved to complete the specs when you wrote
For such a registry to be useful, you also need to standardize the
authentication header across all schemes and define a standard
Well... Can't say I didn't see this coming :)
The issue is not simply about putting a section back, but about the overall
protocol architecture and how it complies with HTTP.
For example, taking the MAC draft, how do you envision the resource server
responding to a failed authentication
Paul,
The draft-15.1 abstract is just the first sentence of the abstract I suggested
last month [http://www.ietf.org/mail-archive/web/oauth/current/msg05693.html
and below]. The rest covered OAuth's other major aspect: issuing temporary
credentials that resource servers can handle, while a
12 matches
Mail list logo
