/hmac'd with the proof-of-possession key where the
audience is the application endpoint and the original access token is included
as a claim.
Yaron
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Friday, September 24, 2010 7:44 PM
To: Yaron Goland; O
licit mechanism.
Yaron
From: PRATEEK MISHRA [mailto:prateek.mis...@oracle.com]
Sent: Friday, September 24, 2010 3:19 PM
To: Yaron Goland
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests?
Yaron,
You have referenced the SAML
No matter what algorithm or key size we pick the choice will prove
unsupportable for any number of implementers due to everything from security
issues (no matter what key size we pick, someone will have a real need for
something larger) to legal issues (various countries have their own opinions
The goal is to have a single unified draft.
From: David Recordon [mailto:record...@gmail.com]
Sent: Monday, September 27, 2010 7:00 AM
To: Nat Sakimura; Yaron Goland
Cc: oauth
Subject: Re: [OAUTH-WG] OAuth Signature Draft Pre 00
I'm a bit confused between the relationship of Nat's I
My understanding of Eran's article
(http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/)
is that Eran believes that bearer tokens are not good enough as a security
mechanism because they allow for replay attacks in discovery style scenarios.
He then, if I understood t
So how do we resolve if the language goes into the spec?
Thanks,
Yaron
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Tuesday, July 27, 2010 8:36 AM
> To: Brian Campbell; oauth
> Subject:
The following is proposed language for inclusion in the spec as section 2.2. I
would like to thank Brian Campbell, Brain Eaton, Chuck Mortimore, Dirk Balfanz,
Eric Sachs, Justin Smith and Marius Scurtescu for taking the time to review and
improve this proposal. Please note that the named folks c
ntent in a HTTP header is to use
some form of ASCII encoding. So, for example, we couldn't use UTF-16 because it
produces characters that aren't safe in ASCII.
> -Original Message-
> From: Robert Sayre [mailto:say...@gmail.com]
> Sent: Tuesday, July 13, 2010 4:01 PM
> To:
As defined in section 4.2 of RFC 2616 the only characters legally allowed in a
HTTP header are a fairly small subset of ASCII. So if we want to shove in
Unicode characters they will have to be encoded in a form that only uses
characters that are legal in the subset of ASCII supported by HTTP.
>
In regards to the discussion of versioning and namespaces I would suggest we
follow RFC 3864. If someone wants to add an extension to OAuth then they can
either write an RFC or they can use the lightweight review mechanism similar to
the one RFC 3864 introduced.
Just a thought,
D
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Recordon
Sent: Thursday, July 08, 2010 9:29 AM
To: OAuth WG
Subject: [OAUTH-WG] POLL: Are you going to Maastricht?
I'm honestly trying to decide myself and a few other people are in similar
situations. Thus a poll
Here is what I think happened.
In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format
arguments were used to allow clients to authenticate themselves to token
endpoints in two legged OAuth scenarios.
In OAuth 2.0 two legged OAuth as a separate definition was removed and instea
Today the definition of scope is vague. But I have seen mails on this list
(such as Lukas Rosenstock's post
http://www.ietf.org/mail-archive/web/oauth/current/msg03560.html which is just
one example) that assert that scope represents the permissions that a client is
requesting.
When we use sco
Message-
> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
> Sent: Wednesday, June 30, 2010 9:18 PM
> To: Yaron Goland; oauth@ietf.org
> Subject: RE: Proposal for text for section 2
>
> Yaron,
>
> > how can you ding client assertions credentials fo
oving this kind of stuff in
the request body.
What do you think?
Yaron
> -Original Message-
> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
> Sent: Tuesday, June 29, 2010 7:30 PM
> To: Yaron Goland; oauth@ietf.org
> Subject: RE: P
Oh and don't forget fun things like including the full cert chain which after
encoding also bloats to amazing heights.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Yaron Goland
> Sent: Wednesday, June 30, 2010 5:39
Or just a bit of XML signatures and encryption. The byte bloat is astounding.
Yaron
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Tuesday, June 29, 2010 11:49 PM
> To: Yaron Goland
> Cc: Marius Scurtescu;
be missing).
EHL
From: David Recordon [mailto:record...@gmail.com]
Sent: Monday, June 28, 2010 6:11 PM
To: Eran Hammer-Lahav
Cc: Yaron Goland; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests
and responses?
For #2, if an extension defines r
This then goes back to one of my original posts which is - Is www-authenticate
legal on a non-401 response? I honestly don't know.
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Monday, June 28, 2010 3:30 PM
To: Yaron Goland; Torsten Lodderstedt
Cc: OAuth WG
Subject: RE: [OAU
assertions. We are thus,
as a practical matter, forced into using the request body.
From: Manger, James H [mailto:james.h.man...@team.telstra.com]
Sent: Monday, June 28, 2010 9:38 PM
To: Yaron Goland; oauth@ietf.org
Subject: RE: Proposal for text for section 2
Yaron,
"Assertion Client Credentials&qu
l of the API. Moreover, authorization headers very well work
> >> together with status code 401 and WWW-Authenticate headers. Using
> >> WWW-Authenticate headers, an authz server can easily signal what
> >> mechanisms (multiple WWW-Authenticate headers are allowed in a single
&g
+1 (for #3->#4)
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Monday, June 28, 2010 11:08 AM
To: Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] What to do about 'realm'
+1
Am 28.06.2010 07:37, schrieb Dick Hardt:
I vote for
OPTIONS.
Thoughts?
Yaron
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Friday, June 25, 2010 11:09 PM
To: Yaron Goland
Cc: Eran Hammer-Lahav; James Manger; OAuth WG
Subject: Re: [OAUTH-WG] OAuth discovery draft?
I think it should
In a private thread with Eran an issue came up regarding how to handle
unrecognized arguments in OAuth requests and responses.
For example, if a token endpoint receives an access token request that contains
both a client_id and a client_foo_bar argument, what should it do? Should it
reject the
ardless whether the
credentials are identical or valid, the server MUST reply with an HTTP 400
status code (Bad Request) and include the "multiple_credentials" error code.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Friday, June 25, 2010 11:31 AM
To: Yaron Goland; oau
rror code.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Friday, June 25, 2010 11:31 AM
To: Yaron Goland; oauth@ietf.org
Subject: RE: Clients authenticating with assertions
We never had support for two assertions in one request.
The client authenticates itself and can include an
Sorry. I screwed up. I somehow missed "none" as an option.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Friday, June 25, 2010 11:20 AM
To: Yaron Goland
Cc: OAuth WG (oauth@ietf.org)
Subject: RE: How do autonomous clients asks for access tokens?
The access grants do not co
ardjono [mailto:hardj...@mit.edu]
> Sent: Wednesday, June 23, 2010 11:40 AM
> To: Yaron Goland; OAuth WG (oauth@ietf.org)
> Subject: RE: OAuth discovery draft?
>
>
> Hi Yaron,
>
> I think delegation is a great idea/feature that should be added or OAuth (as I
> sugge
If a client wants to authenticate itself to a token endpoint to get an access
token using an assertion how should it do it?
Grant_Type = assertion doesn't seem right because that assertion should be from
the resource owner who delegated the permission, not from the client, right? In
other words
Section 1.4.4 says that autonomous clients can get access tokens. But how? What
grant_type should they use?
Thanks,
Yaron
P.S. I looked for a grant_type of autonomous but I didn't see it in -08. Sorry
if I missed it.
Thanks,
Yaron
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Wednesday, June 23, 2010 11:04 AM
To: Yaron Goland; James Manger; OAuth WG
Subject: Re: OAuth discovery draft?
I think the core work is pretty stable now, unlike the discovery bits which
(while simpl
I've been noodling [1] a lot about full delegation in OAuth [2] and one of the
issues that came out of that was the need for discovering both the location and
realm of an endpoint's token server. But at least for my use cases (which
consist of walking up to a service and making an options reques
ginal Message-
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
> Sent: Tuesday, June 08, 2010 3:11 PM
> To: Yaron Goland; oauth@ietf.org
> Subject: RE: Questions about sections 3.2/3.3
>
>
>
> > -Original Message-
> > From: oauth-boun...@ietf.org [m
Since there was no response to this mail may I assume it went to /dev/null?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Yaron
Goland
Sent: Thursday, May 20, 2010 12:20 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Questions about sections 3.2/3.3
I was reading through
I was reading through the spec and had some questions about 3.2 and 3.3 that I
list below.
Thanks,
Yaron
Section 3.2/3.3 - Handling requests without supported transport layer security
Although optional in section 3.2 and mandatory in section 3.3 bot
; Or I guess you can make it so OAuth is only for JSON APIs because JSON is the
> future. Though I seem to remember that being said about XML not long ago.
> Maybe I'm getting old. I guess I shouldn't use RSS and Atom feeds because
> they are so last year.
>
> I'm for option C
Note that in some very popular browsers and some proxies the maximum safe URL
size is more like 2k.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Dick Hardt
> Sent: Sunday, May 16, 2010 5:27 PM
> To: Manger, James H
> Cc: OAuth WG (oaut
't require discovery, user interaction or a change to the
existing protocol.
Yaron
> -Original Message-
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
> Sent: Tuesday, May 11, 2010 4:36 PM
> To: Yaron Goland; Manger, James H; OAuth WG (oauth@ietf.org
iginal Message-
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
> Sent: Tuesday, May 11, 2010 4:37 PM
> To: Yaron Goland; Torsten Lodderstedt
> Cc: OAuth WG (oauth@ietf.org)
> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
>
> No one
(weak or otherwise) exists for C. Could you please explain your reasoning?
Thanks,
Yaron
Vivek Khurana - A or B but not C
Yaron Goland - A then B but not C
David Waite - A or B but doesn't like C
Mike Moore - A (but not C)
Dick Hardt - B
James H Manger - B
Torsten
,
Yaron
From: Manger, James H [mailto:james.h.man...@team.telstra.com]
Sent: Monday, May 10, 2010 5:31 PM
To: Yaron Goland; OAuth WG (oauth@ietf.org)
Subject: RE: sites with wildcard
Yaron,
> I don’t understand the scenario that requires this feature. When d
submitted.
Yaron
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Monday, May 10, 2010 10:47 PM
> To: Yaron Goland
> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Open Issues: Group Surv
Limited views on what a protocol is far tend to produce protocols that are
actually interoperable. We should strive to do as little as possible in the
standard and make sure we do a great job leaving the door open to later
extensions.
> -Original Message-
> From: oauth-boun...@ietf.org
+1
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Monday, May 10, 2010 4:11 PM
> To: Manger, James H
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] sites with wildcard
>
> On Mon, May 10, 2010 at 7:32 AM, M
I don’t understand the scenario that requires this feature. When does someone
ask for a token without knowing where it is going?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Monday, May 10, 2010 7:33 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OA
ller group but with
> stronger feelings on the subject that JSON adds complexity with no obvious
> value.
>
> A. Form-encoded only (original draft)
> B. JSON only (current draft)
> C. JSON as default with form-encoded and XML available with an optional
> request parameter
>
[Yaron G
+1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Moore
Sent: Friday, May 07, 2010 8:06 AM
To: OAuth WG
Subject: [OAUTH-WG] application/x-www-form-urlencoded Counterproposal
I propose alter the spec so that the token responses are encoded with
application/x-www-f
Every format we add increases the probability of failing to interoperate.
I believe as a working group we need to specify exactly one format and only one
format. That doesn't preclude later extensions that support more formats but if
our goal is interoperability then the fewer options the more
AUTH-WG] application/x-www-form-urlencoded vs JSON
> (Proposal)
>
>
> Zitat von Brian Eaton :
>
> > On Thu, Apr 29, 2010 at 2:40 PM, Mike Moore
> wrote:
> >> On Thu, Apr 29, 2010 at 2:49 PM, Yaron Goland
> wrote:
> >>>
> >>> Can we p
Can we please just have one format, not 3? The more choices we give the more
interoperability suffers.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Thursday, April 29, 2010 12:46 PM
> To: Robert Sayre
> Cc:
50 matches
Mail list logo
