Sending to the right place.
From: Shiu Fun Poon [mailto:shiufunp...@gmail.com]
Sent: Wednesday, June 20, 2012 5:40 PM
To: draft-ietf-oauth...@tools.ietf.org
Subject: [comment] The OAuth 2.0 Authorization Framework draft-ietf-oauth-v2-28
I am not sure whether you are accepting comments for the
From: artem.obotu...@orange.com [mailto:artem.obotu...@orange.com]
Sent: Wednesday, April 18, 2012 8:09 AM
To: Eran Hammer
Subject: typo in OAuth 2.0 spec draft v25
Dear Eran.
In draft v25 of The OAuth 2.0 spec on Figure 4 : Implicit Grant Flow, step G is
not documented among steps
This boils down to whether the registration template can contain all the
detailes required for interoperability or not. If not, you need a specification.
EH
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Mike Jones
Sent: Saturday, June
It is pretty obvious these refer to the two well defined endpoints in section
3. I will add a reference next to the locations to make this even clearer.
There is no such endpoint as client authentication as a location. OAuth core
clearly defines three endpoints for which two are extensible via
Cc: Hannes Tschofenig; Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Section 7.2
Hi Mike,
this text below does not prohibit error information to be sent back to the
client (otherwise there would be a MUST NOT).
So, if a developer reads this below then when
I would rather these restrictions be in the error registry section below and
add a forward reference from 7.2.
EH
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Saturday, June 16, 2012 12:17 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2
We already have multiple registries. This one is about error codes only. I
don't think the overlap is clear at this point between errors on the core
endpoints vs error on the bearer and future auth schemes opting into this
registry. So it is hard to tell which format would be better. The main
These are straight link relation registrations, not LRDD (which has no
registration process). It is helpful to put these registrations in context and
use LRDD/host-meta as an example of their use, but the actual registration
request is simply for a link relation and nothing else.
EH
host-meta as one
example, and maybe Link headers in a 401 response as another example.
EH
-Original Message-
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Wednesday, June 13, 2012 11:39 AM
To: Eran Hammer; O Auth WG; Apps Discuss
Subject: Re: [OAUTH-WG] OAuth discovery
Is the use case of using URI as client ids important? It seems like something
that might become useful in the future where clients can use their verifiable
servers to bypass client registration and simly use a URI the server can
validate via some other means.
I just want to make sure those
for redirections including a fragment) about it.
EH
From: George Fletcher [mailto:gffle...@aol.com]
Sent: Tuesday, June 12, 2012 11:44 AM
To: Eran Hammer
Cc: Mike Jones; William Mills; Hannes Tschofenig; Julian Reschke; oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF
...@microsoft.com]
Sent: Saturday, June 02, 2012 1:08 AM
To: Eran Hammer; Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: RE: [OAUTH-WG] Error Encoding: Conclusion
After speaking with the chairs, I volunteered to write a draft of the ABNF
text
to keep things moving towards completion. An updated
-Original Message-
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Thursday, May 31, 2012 1:53 PM
To: Eran Hammer; Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: RE: [OAUTH-WG] Error Encoding: Conclusion
Actually, could you please publish before the ABNF is done so
I don't care about this either way, but 'explicitly rejected' is an over-reach.
I have not seen the chairs make a consensus call about that, or even formally
ask the list.
EH
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Mike Jones
In order to make the prescribed change, new text is needed:
* New subsection for section 7 (Accessing Protected Resources) providing
guidelines for use of the new 'resource access error response' error registry:
1. What are the valid cases in which a 'resource access error response' may
be
, May 11, 2012 12:00 AM
To: Eran Hammer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer
Spec
Hi Eran,
At 16:04 09-05-2012, Eran Hammer wrote:
The IESG members rely on the editor to represent the WG decisions to
them when addressing issues. You
] Encoding of Errors in the Base and in the Bearer
Spec
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer
Sent: Friday, May 11, 2012 12:19 AM
To: SM
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Encoding of Errors in the Base
What exactly is the expected WG discussion on this? I hope people here are not
expected to read the patent and make legal decisions about the patent's
validity or even applicability as these are questions for lawyers, not
engineers.
EH
-Original Message-
From: oauth-boun...@ietf.org
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Wednesday, May 09, 2012 11:37 AM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] IPR on OAuth bearer
Hi Eran,
if you care about the specification (and want to use
Thanks. This is the clarification I was seeking.
EH
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Wednesday, May 09, 2012 12:17 PM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] IPR on OAuth bearer
No, don't
12:34 PM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] IPR on OAuth bearer
On 05/09/2012 12:17 PM, Eran Hammer wrote:
Whoever you talk to for legal advice about IPR issues related to standards
you might implement. My only point is, this group
I am confused by the process here.
The IESG review raised a LONG list of discuss items for the core specification.
I was able to successfully address all but three remaining issues:
1. Lack of ABNF - I will do it myself this week since no one else bothered to
offer their help.
2. Registry
consensus regarding the
scope of the error registry in the core spec, and only suggesting adding a
registry in the bearer for that purpose alone.
EH
-Original Message-
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Wednesday, May 09, 2012 4:33 PM
To: Eran Hammer
Most people on this WG are not aware of all the details around the on-going
IESG review and my objections to making additional changes to the core
specification. Currently, these are the open issues preventing the bearer
specification from being approved:
From Russ Housley:
Section 3.1
Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Framework
Author(s) : Eran Hammer
David Recordon
Dick Hardt
Filename: draft-ietf-oauth-v2-26.txt
Pages : 66
Thanks! This removes all my concerns about the charter.
EH
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Thomas Hardjono
Sent: Thursday, April 26, 2012 11:25 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Updated Dynamic Registration draft
During the IESG review of draft-ietf-oauth-v2, Sean Turner raised the following
DISCUSS item (meaning, the specification is blocked until this is resolved):
0) General: I found the lack of ABNF somewhat disconcerting in that
implementers would have to hunt through the spec to figure out all
We can do both (provide it as defined and in one section). But someone needs to
prepare all the ABNFs first.
EH
From: Chuck Canning [mailto:chuck.cann...@deem.com]
Sent: Monday, April 23, 2012 3:28 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: OAuth ABNF
As someone trying
#1 as John Panzer identified, allowing the server to control its deployment and
supporting HTTP redirects is critical.
#2 JSON is better, which one is required is less of on issue but more of a best
practices item.
I'll add:
* Highly cachable
* Optimize for large providers, reducing the need
Because it is in the draft the WG is suppose to consider. It's a stated
dependency.
EH
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, April 18, 2012 12:50 PM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re
WFM. An updated I-D without it would be great.
EH
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, April 18, 2012 12:57 PM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Dynamic Client Registration
I'd like to see 'Dynamic Client Registration' removed from the charter along
with SWD for the sole reason that figuring out a generic discovery mechanism is
going to take some time and this WG has enough other work to focus on while
that happens elsewhere. I expect this to come back in the next
Tone aside, this is not the first time you distorted process and technical
facts to suit your goals. Just look up some of our exchanges from a year ago
and the transcript of the Prague meeting for highlights.
EH
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
complete, the WG may choose to delay work on this document until ready.
EH
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Sunday, April 15, 2012 9:01 AM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Dynamic Client
With the exception of SWD which is still being discussed, this looks good.
EH
On Apr 12, 2012, at 6:55, Hannes Tschofenig hannes.tschofe...@gmx.net wrote:
Hey guys
based on the discussion before, during, and after the Paris IETF meeting I am
going to send the following updated charter /
Where is this access control and user centric architecture described? I could
not find it.
EH
On Apr 12, 2012, at 14:01, John Bradley ve7...@ve7jtb.com wrote:
There are important deployment and privacy issues that caused openID Connect
to use SWD.
I was part of the OASIS XRI/XRD work
Issue 2 received extensive WG discussion.
At the core of it was the question of how the IETF should handle HTTP
authentication error codes. We consults with the HTTPbis WG and consensus was
that at this point we do not want to create a general purpose error registry
for HTTP authentication
, March 29, 2012 11:15 PM
To: Eran Hammer; William Mills; s...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
Yes, you are missing the meeting we had yesterday where it was discussed to be
added to the charter.
-derek, WG Chair
Sent from my HTC on the Now Network from
-Original Message-
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Thursday, March 29, 2012 11:13 PM
To: Eran Hammer; Derek Atkins; s...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
Thanks for the process lecture except we already had
Hi Derek,
Thanks for the notes. Is an audio recording available?
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Derek Atkins
Sent: Thursday, March 29, 2012 8:27 AM
To: s...@ietf.org; oauth@ietf.org
Subject: [OAUTH-WG] OAUTH Report for
something here?
EH
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Thursday, March 29, 2012 4:26 PM
To: Eran Hammer; Derek Atkins; s...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83
On the SWD stuff there was general discussion about is this the right place
.
John B.
On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
In my opinion, dynamic client registration would allow us to drop public client
thus simplifying the core spec.
regards,
Torsten.
Am 15.03.2012 16:00, schrieb Eran Hammer:
I believe most do, except for the dynamic client
seems to be too strong for many people.
Better?
EH
-Original Message-
From: breno.demedei...@gmail.com
[mailto:breno.demedei...@gmail.com] On Behalf Of Breno
Sent: Saturday, March 17, 2012 8:50 AM
To: Eran Hammer
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth
Mike, Nat,
Does the new text work for you?
EH
-Original Message-
From: breno.demedei...@gmail.com
[mailto:breno.demedei...@gmail.com] On Behalf Of Breno
Sent: Saturday, March 17, 2012 12:10 PM
To: Eran Hammer
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0
I am treating this issue as closed, unless someone wants to proposed language
changes based on John's analysis below.
EH
-Original Message-
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Thursday, March 08, 2012 8:13 AM
To: Eran Hammer
Cc: Julian Reschke; i...@ietf.org
This add-on is unnecessary. It already says the authorization server can handle
it any way it wants. The fact that other registration options are possible
clearly covers the client identifier reuse case. As for the response type,
that's not an issue but more of an optimization for an edge case
The only reason it is taking a long time is lack of WG feedback and total lack
of attention from the chairs. If you are looking to improve delivery time, I
would start by getting more involved and help drive issues to completion.
Suggesting the problem is with the single author is unfounded and
I believe most do, except for the dynamic client registration. I don't have
strong objections to it, but it is the least important and least defined /
deployed proposal on the list. The AS-RS work is probably simpler and more
useful at this point.
EH
-Original Message-
From:
, 15 Mar 2012 09:56:13 -0700
To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com
Cc: Nat Sakimura sakim...@gmail.commailto:sakim...@gmail.com, OAuth WG
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
On Thu, Mar 15, 2012 at 07:45
if the
resulting text is confusing and possibly misleading. Better to say
nothing instead.
On Thu, Mar 15, 2012 at 11:32, Eran Hammer e...@hueniverse.com wrote:
Here are the facts:
The authorization server must know the client type in order to enforce
many
of the requirements
the entire principle of why two response_type 'code' and 'token' were
defined, and how OAuth2 is typically implemented. That's when I claim
this normative language is redefining the protocol.
On Thu, Mar 15, 2012 at 12:13, Eran Hammer e...@hueniverse.com wrote:
Which text in -25 are you proposing
-Original Message-
From: Breno de Medeiros [mailto:br...@google.com]
Sent: Thursday, March 15, 2012 2:12 PM
To: Eran Hammer
Cc: Nat Sakimura; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
On Thu, Mar 15, 2012 at 13:13, Eran Hammer e...@hueniverse.com
wrote
This was already raised and addressed on this list last week.
When someone defines and registers code+token, that specification must define
how such a client is registered in light of the text below. This might mean
defining a new client type, choosing the confidential client type with other
different client
identifiers to such complex clients. I think this is another point missed in
your reading of the text.
Hope this clarifies it.
EH
-Original Message-
From: Breno de Medeiros [mailto:br...@google.com]
Sent: Wednesday, March 14, 2012 10:16 AM
To: Eran Hammer
Cc: Marius
[mailto:mscurte...@google.com]
Sent: Wednesday, March 14, 2012 11:24 AM
To: Eran Hammer
Cc: Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Before v23 a web server client could use either response_type=code or
response_type=token, with the same client
[mailto:michael.jo...@microsoft.com]
Sent: Wednesday, March 14, 2012 11:42 AM
To: Eran Hammer; Marius Scurtescu
Cc: Breno de Medeiros; OAuth WG
Subject: RE: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
All of Marius, Breno, Nat, myself, and several others on the OpenID AB list
have read
Looks great!
Not sure if 'JSON Web Token (JWT)' belongs on this list, but not a big problem.
EH
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Hannes Tschofenig
Sent: Wednesday, March 14, 2012 1:21 PM
To: oauth@ietf.org WG
Subject:
I am strongly opposed to SWD being part of *this* working group. My objection
is based on:
1. This is clearly an APP area document, not a SEC area document. Getting
this work done through the OAuth WG will skip the most relevant audience for
this document as a general purpose tool.
2.
The best way is to get some drafts going and then revisit after the proposed
charter is completed. I think the 5 new items limit along with the existing
work is as much as this WG can take for the time being.
Getting some market experience would be great too.
EH
-Original Message-
-Original Message-
From: Richer, Justin P. [mailto:jric...@mitre.org]
Sent: Wednesday, March 14, 2012 7:51 PM
[...] the AS-PR connection is a real and present known
gap introduced in OAuth2 (since OAuth1 didn't even think of them as
separate entities) and *somebody* should be
If you have two components each with different security profile, you must
assign each a different client_id. Otherwise, there is no way to enforce the
rest of the spec's security requirements.
EH
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
in the future
will have to figure out how this should be handled.
EH
-Original Message-
From: nov matake [mailto:n...@matake.jp]
Sent: Sunday, March 11, 2012 10:21 AM
To: Eran Hammer
Cc: nov matake; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Clarification of client application
Yep. Forgot to drop the NOT. Want a new -25?
EH
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Thursday, March 08, 2012 2:32 AM
To: Eran Hammer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt
Thanks Eran
I pushed -25 just in case with this fix.
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Thursday, March 08, 2012 2:32 AM
To: Eran Hammer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt
Thanks Eran
Sending to the full list.
-Original Message-
From: Roger Crew [mailto:c...@cs.stanford.edu]
Sent: Saturday, December 31, 2011 12:47 AM
To: Eran Hammer-Lahav; Adam Barth; Ben Adida
Subject: comments on oauth-v2-http-mac-00
Hi,
I have some comments on the now-expired http_hmac draft
-Original Message-
From: Henry S. Thompson [mailto:h...@inf.ed.ac.uk]
Sent: Tuesday, February 14, 2012 9:07 AM
11 It seems at best old-fashioned that the designer of a new access
token type, parameter, endpoint response type or extension error has
no better tool available than
Added:
unsupported parameter value (other than grant type)
EH
-Original Message-
From: Roger Crew [mailto:c...@cs.stanford.edu]
Sent: Tuesday, February 07, 2012 12:53 PM
To: Eran Hammer
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1
-Original Message-
From: Songhaibin [mailto:haibin.s...@huawei.com]
Sent: Friday, February 17, 2012 12:53 AM
To: Justin Richer
Cc: tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org; Martin
Stiemerling; oauth@ietf.org; tsv-...@ietf.org
Subject: RE: [OAUTH-WG] tsv-dir
Can't validate, but can sanitize.
EH
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Andrew Arnott
Sent: Sunday, February 19, 2012 7:36 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] How an AS can validate the state parameter?
From section 10.14: (draft 23)
The
Invalid_grand is correct.
EH
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Buhake Sindi
Sent: Tuesday, February 21, 2012 7:16 AM
To: Peter Brindisi
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] error response for invalid refresh token
Hi
invalid_grant
The provided
PM
To: Peter Saint-Andre
Cc: Eran Hammer; OAuth WG
Subject: Re: [OAUTH-WG] Server cret verification in 10.9
We added the reference to RFC6125 in openID Connect.
The Client MUST perform a TLS/SSL server certificate check, per
xref target=RFC6125RFC 6125/xref.
We wanted
Thanks Haibin.
-Original Message-
From: Songhaibin [mailto:haibin.s...@huawei.com]
Sent: Wednesday, February 15, 2012 1:33 AM
Nits:
1. Section 3.1, paragraph 4, the last sentence is confusing, is it the
authorization server who sends the request to the authorization endpoint?
Or
-Original Message-
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Monday, February 06, 2012 5:07 PM
To: Eran Hammer
Cc: Julian Reschke; i...@ietf.org; The IESG; oauth@ietf.org
Subject: Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The
OAuth 2.0 Authorization Protocol: Bearer
Section 3.1.1 states:
If an authorization request is missing the response_type parameter,
the authorization server MUST return an error response as described
in Section 4.1.2.1.
The intention was to make this the catch-all scenario. While I do appreciate
the issue here of the client
Should simple read the attacker's user-agent is sent to.
EH
-Original Message-
From: Songhaibin [mailto:haibin.s...@huawei.com]
Sent: Wednesday, March 07, 2012 6:11 PM
To: Eran Hammer; tsv-...@tools.ietf.org; draft-ietf-oauth...@tools.ietf.org
Cc: tsv-...@ietf.org; oauth@ietf.org
: draft-ietf-oauth-v2-24.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : Eran
Can you give an example where an unknown parameter being ignored can lead to
security issues?
EH
From: John Bradley ve7...@ve7jtb.commailto:ve7...@ve7jtb.com
Date: Thu, 16 Feb 2012 11:55:21 -0700
To: William Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com
Cc:
: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Eran Hammer
Sent: Thursday, 9 February 2012 4:55 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt
Main changes:
Removed cookies support
Removed body hash
Clarified timestamp verification
Purely editorial.
EH
On Feb 15, 2012, at 15:09, Barry Leiba barryle...@computer.org wrote:
Do you have changes to make based on the Apps and TSV Directorate reviews?
Barry
___
OAuth mailing list
OAuth@ietf.org
Last call ended 2/6. I have got some notes but nothing significant. I think I
can resolve all of them with editorial tweaks. I am planning on posting -24
this week and get this ready for IESG review.
Any comments?
EH
___
OAuth mailing list
The text serves two purposes:
1. Warn client developers that the server may have a default scope and
that they should figure out what it is or what the scope requirements are
2. Make server developers aware that they should publish their default
scope of scope handling
: HTTP Authentication: MAC Access Authentication
Author(s) : Eran Hammer-Lahav
Filename: draft-ietf-oauth-v2-http-mac-01.txt
Pages : 20
Date: 2012-02-08
This document specifies the HTTP MAC access authentication scheme
New draft:
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01
EH
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Erlend Hamnaberg
Sent: Tuesday, February 07, 2012 11:02 AM
To: OAuth@ietf.org
Subject: [OAUTH-WG] Implementing MAC bearer
Hi guys and gals.
I am
-Original Message-
From: Henry S. Thompson [mailto:h...@inf.ed.ac.uk]
Sent: Tuesday, February 07, 2012 9:31 AM
To: apps-disc...@ietf.org; barryle...@gmail.com; dick.ha...@gmail.com;
d...@fb.com; Eran Hammer; hannes.tschofe...@gmx.net; stephen.farr...@cs.tcd.ie
Cc: i...@ietf.org
Subject
Sending to the right place.
From: Thomas, Christopher (LLU) [mailto:cwtho...@llu.edu]
Sent: Monday, February 06, 2012 11:33 AM
To: draft-ietf-oauth...@tools.ietf.org
Subject: Mail regarding draft-ietf-oauth-v2
Hello,
I'm looking into implementing the Oauth2 spec for a work project and I think I
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, January 26, 2012 6:07 AM
To: Eran Hammer
Cc: OAuth WG
Subject: Re: [OAUTH-WG] AD Review of -22 (part II)
I realize that -23 is already published with the below text, but since this
is a
whole
People seems confused about the issue raised by Julian. It is pretty simple.
The HTTP WWW-Authenticate header definition allows each header parameter to
have a quoted string or token value. Token values are very restrictive and not
suitable for scope (no spaces, etc.). Quoted strings allow a
, January 23, 2012 1:23 AM
To: Eran Hammer
Cc: William Mills; oauth@ietf.org
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in
Specification
Den 20. jan. 2012 kl. 21:32 skrev Eran Hammer:
New text added to Access Token Scope section:
If the client omits
Added to section 1:
TLS Version
Whenever TLS is required by this specification, the appropriate
version (or versions) of
TLS will vary over time, based on the widespread deployment and known
security
vulnerabilities. At the time of this writing, TLS version 1.2
. The authorization server SHOULD document
its scope
requirements and default value (if defined).
EHL
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 10, 2012 11:58 PM
To: Eran Hammer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity
The current text:
If the issued access token scope
is different from the one requested by the client, the authorization
server SHOULD include the scope response parameter to inform the
client of the actual scope granted.
Stephen asked why not a MUST. I think it should be MUST. Any
Stephen asked:
(13) 10.9 says that the client MUST verify the server's cert which is fine.
However, does that need a reference to e.g. rfc 6125?
Also, do you want to be explicit here about the TLS server cert and thereby
possibly rule out using DANE with the non PKI options that that WG
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Thursday, October 13, 2011 10:13 AM
List 1 - Fairly sure these need changes:
(1) In 2.3.1 MUST the AS support both HTTP
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Stephen Farrell
Sent: Thursday, October 13, 2011 10:13 AM
Original list of nits:
--
- Intro: Maybe add some ascii-art showing the roles of the user, browser,
client
the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : Eran Hammer
David Recordon
Dick
In the case of section 5, because this is a direct interaction with the client,
the server should issue a 5xx response instead.
EHL
From: Antonio Sanso [mailto:asa...@adobe.com]
Sent: Thursday, January 19, 2012 9:06 AM
To: Eran Hammer
Cc: OAuth WG
Subject: Re: Error code for access token
interop.
I’m going to go with adding: If omitted, the authorization server SHOULD
provide the expiration time via other means or document the default value.
EHL
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Tuesday, January 17, 2012 12:02 AM
To: Eran Hammer; Aaron Parecki; OAuth WG
Cc
Should this be added to the security model document? Is it already addressed
there?
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of André DeMarre
Sent: Tuesday, October 04, 2011 11:33 AM
To: OAuth WG
Subject: [OAUTH-WG] Phishing
Compliant - sure. Smart - well, that depends on the use case. OAuth provide a
very flexible framework (mostly because we could not agree more on
restrictions). This means you can follow the spec and produce bad or insecure
implementation. The spec does warn against such issues, and in the case
Added:
scope = scope-token *( SP scope-token )
scope-token = %x21 / %x23-5B / %x5D-7E
EHL
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Tuesday, October 18, 2011 9:40 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf
1 - 100 of 1089 matches
Mail list logo
