I do not want to allow the client any flexibility in choosing the algorithm
once a MAC key has been issued. Every other standard provide a negotiation step
in which the client can figure out which algorithms are available, and
therefore needs to indicate which one was used. I don't want to suppo
> -Original Message-
> From: Skylar Woodward [mailto:sky...@kiva.org]
> Sent: Thursday, January 27, 2011 3:52 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02
>
> This is excellent. Thanks for pulling together a signature-based token
I am in the midst of editing a new version which includes a few breaking
changes such at header attribute name changes ('token' to 'id', 'signature' to
'mac') as well as a new attribute ('issuer' to indicate the host:port where the
credentials were issues - in OAuth, the host and post of the aut
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 se
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 attempt
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 paramet
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 headers
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 re
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 co
Thanks for writing this up, Eran. I believe that this is a step in the right
direction.
Wearing my Bearer Token spec editor hat, I just tried to go through the
exercise of editing my document to use the registry in draft 15 to register the
errors defined in the bearer token spec and I hit a ro
Well, I should elaborate. The method of authorization is open to the client,
and in this case (Kiva), MAC tokens are being used. The client authenticates on
the access_token request by presenting a MAC authentication header. Creating
the MAC signature requires a secret. In the native client case
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
di
New text:
Extension error codes MUST be registered (following the procedures in
) if the extension they are used in
conjunction with is
a registered access token type, a registered endpoint parameter, or
an extension grant
type. Error codes used with unreg
Done.
EHL
Ps. I like 1974.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Tuesday, April 05, 2011 5:51 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-15 editorials
A few, mainly editorial, points on the latest OAuth 2.0 core draft
[draft-ietf-
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
OA
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 h
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, chang
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 cla
18 matches
Mail list logo
