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
.
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 browser SSO protocol
-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; OAuth WG
Subject: Re: [OAUTH-WG
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-D
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
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: Re:
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
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: Yaron Goland
Cc: Eran Hammer-Lahav; OAuth
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.
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
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
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
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: Proposal for text for section 2
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 is too
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: [OAUTH-WG
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 required parameters then you're
in 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
+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
-Authenticate headers are allowed in a single
HTTP response) it accepts for a particular request.
regards,
Torsten.
Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav:
Yaron Goland offered a proposal for an additional client credentials
mechanism based on assertion. His proposal raises
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.
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
, 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
suggested in the kerberos-oauth draft). In the Kerberos world, it has been a
very important
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 correlate
[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 assertion (or use type
'none'). The client
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
,
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 simple
-
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 [mailto:oauth-boun...@ietf.org] On Behalf
Of Yaron Goland
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
[mailto:say...@gmail.com]
Sent: Thursday, May 13, 2010 4:27 PM
To: Eran Hammer-Lahav
Cc: Yaron Goland; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav
e...@hueniverse.com wrote
.
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 Survey (respond by 5/13)
Am 11.05.2010 01:43
,
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 does someone
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 Goland] I prefer A, can live with B and object to C.
---
2. Client Authentication (in flows)
How should the client
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
vs JSON
(Proposal)
Zitat von Brian Eaton bea...@google.com:
On Thu, Apr 29, 2010 at 2:40 PM, Mike Moore blowm...@gmail.com
wrote:
On Thu, Apr 29, 2010 at 2:49 PM, Yaron Goland yar...@microsoft.com
wrote:
Can we please just have one format, not 3? The more choices we give
the more
35 matches
Mail list logo
