Well, I guess I better get going with the SASL thing and get a working
implementation done based on -12 and the bearer token spec.
> -Original Message-
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
> Sent: Wednesday, January 26, 2011 7:27 PM
> To: William Mills; Marius Scurtescu
This is a good example of why this is currently out of scope. We have little to
no implementation experience with such a setup.
EHL
> -Original Message-
> From: William Mills [mailto:wmi...@yahoo-inc.com]
> Sent: Wednesday, January 26, 2011 3:17 PM
> To: Eran Hammer-Lahav; Marius Scurtes
So technically, this is not a token endpoint, per OAuth 2.0, but an endpoint
where you can get tokens using some other parameters and headers. This is
perfectly fine, but is using a different design.
EHL
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Wednesd
On Wed, Jan 26, 2011 at 2:53 PM, Eran Hammer-Lahav wrote:
> Can you share what the actual request looks on the wire? How are you passing
> the Kerberos authentication in the request? What do you set the grant type to?
Most of this pre-dates grant type and the OAuth2 brand. =)
>From memory, the
On Wed, Jan 26, 2011 at 2:53 PM, Eran Hammer-Lahav wrote:
> Can you share what the actual request looks on the wire? How are you passing
> the Kerberos authentication in the request? What do you set the grant type to?
Most of this pre-dates grant type and the OAuth2 brand. =)
>From memory, the
Actually I was envisioning a situation where you have multiple possibly
disparate endpoints that rely on authenticator like Google or Yahoo. One
company decides they want to allow federated login and accept SAML assertions,
another accepts bearer, yet a 3rd IMAP server accepts both some form of
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Wednesday, January 26, 2011 1:43 PM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> >> 1. The token_type parameter is required in responses
Can you share what the actual request looks on the wire? How are you passing
the Kerberos authentication in the request? What do you set the grant type to?
EHL
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Wednesday, January 26, 2011 2:02 PM
> To: Eran Hamme
Can you explain how having to define *two* extension parameters makes the
specification useless? The bearer token specification is going to define its
corresponding WWW-Authenticate header, to match its already defined
Authorization header. The scheme name is just style and branding and have
ab
On Wed, Jan 26, 2011 at 2:29 PM, Eran Hammer-Lahav wrote:
> How about turn the MUST to a SHOULD for using the x_ prefix?
OK, let's go with that.
Thanks,
Marius
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
How about turn the MUST to a SHOULD for using the x_ prefix?
EHL
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Wednesday, January 26, 2011 1:32 PM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-1
MAC is clearly trying to define something generic and includes an OAuth
binding. I think the bearer token is the exception of something completely
useless outside of OAuth, but that doesn't mean it uselessness should promote
it to the canonical authentication scheme, all of which was already dea
On Wed, Jan 26, 2011 at 9:07 AM, Eran Hammer-Lahav wrote:
> Can you share an actual example of how you are authenticating *both* the
> resource owner and client in a single request?
That's not a business requirement.
So the desired flow goes like this:
kerberos (or other magic sauce) authe
The client aut6hetication assertion was also discussed many times and a lot in
the July/August time frame. I don’t believe that the introduction of client
assertion was a violation as this came from the merge of WRAP into OAUTH 2.0
and has been there for many drafts and then all of a sudden to d
Maybe this was the plan all along but specification is becoming useless for our
scenarios and will require that we have to go well beyond the core
specification to make things work, the client assertion credentials being a
prime example. The client assertion credentials has been around for a whi
Am 25.01.2011 10:25, schrieb Bob Gregory:
Perhaps I'm missing something here, but once a client has requested an
access grant, the auth server is free to authenticate the end-user in
whatever way it chooses, and it would seem sensible to signal authn
requirements with standard HTTP headers.
W
On Tue, Jan 25, 2011 at 11:08 PM, Eran Hammer-Lahav wrote:
> Thanks Marius.
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Tuesday, January 25, 2011 5:02 PM
>> To: Eran Hammer-Lahav
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] I-D Action:draft
On Wed, Jan 26, 2011 at 9:48 AM, Eran Hammer-Lahav wrote:
> This is not aimed at anyone in particular.
>
> Replying +1 is not justification for a major breaking change. This was raised
> in the past and consensus was that this is not a major concern. Over the past
> 10 months not a single actual
On Tue, Jan 25, 2011 at 9:59 PM, Eran Hammer-Lahav wrote:
> Simply because authentication is not what OAuth is about.
>
> OAuth is an authorization protocol for issuing access tokens. Access tokens
> can have different properties and therefore need different schemes. I was the
> first to suggest
Hi Tim,
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
1. Evil user starts the OAuth flow on the client using the web-server flow.
2. Client redirects the evil user to the authorization server, including state
information about the evil user account on the client.
3. Evil user takes the au
On Tue, Jan 25, 2011 at 6:34 PM, William Mills wrote:
> As I remember there was serious objection by a few to putting versioning in
> the scheme name. OAuth, OAuth2, and soon we're on OAuthN+1 seemed to be the
> objection. Some are passionate about it and no one was sufficiently
> passionate
- 4.1. Authorization Code. It is stated that authorization code is
suitable for clients that can hold a secret. Not necessarily true, it
is the best flow for native apps, for example.
- 4.1.2 Authorization Response. Minor typo in last sentence on page
16: "size of any value is issues" => "size of
This is not aimed at anyone in particular.
Replying +1 is not justification for a major breaking change. This was raised
in the past and consensus was that this is not a major concern. Over the past
10 months not a single actual issue was raised about conflicts in legacy
platforms. If you have
+1
More feedback on the token specs (and v12) is in my queue for tonight, but this
has also been a concern of mine and this seems to be a more elegant protection
against conflicts than adding a "version" parameter.
On Jan 26, 2011, at 6:14 PM, William Mills wrote:
>>> Broken record: using a pr
> > Broken record: using a prefix for all registered parameters is
> > much cleaner (as opposed to requiring that all no-registered
> > parameters use a prefix).
>
> And once again, a strong +1 to this, even though I know it's far too
> late to make such a breaking change to the spec. I really thi
Can you share an actual example of how you are authenticating *both* the
resource owner and client in a single request?
EHL
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Wednesday, January 26, 2011 9:01 AM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; O
On Tue, Jan 25, 2011 at 10:58 PM, Eran Hammer-Lahav wrote:
>> What's the difference from a conceptual point of view? In my opinion, the
>> resource owners password is used for both, authenticating the resource
>> owner and authorizing the token issuance.
>
> The resource owner is not present and t
OK, thanks for clarifying. Back to your original questions.
We've been handling this mostly in a single shared token endpoint. In
a few cases we've gone with separate end-points because it made things
easier. We've kept parameters such as scope consistent, since they
are properties of the outpu
No clue, but what difference does it make? Either you "pollute" the OAuth
header namespace or the HTTP Authentication scheme name namespace. What's the
difference? Either way, I would be surprised if we see more than 10 token types
over the next 5 years.
EHL
> -Original Message-
> From
I question how much name space pollution is a problem, how many auth schemes
are we really going to have?
> -Original Message-
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
> Sent: Wednesday, January 26, 2011 12:49 AM
> To: William Mills
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG]
This belongs in the security consideration section.
Torsten - can you add it to your list?
EHL
From: Eric [mailto:pf...@cs.stanford.edu]
Sent: Friday, January 21, 2011 12:31 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] validate authorization code in draft 12
Eran, and others
And also not much adoption into older (established) systems, yet. That's
where I see the trouble really happening. Most of the deployments we've
seen with OAuth2 have been with new systems or custom-built websites
where the devs had full control over API parameters.
-- Justin
On Wed, 2011-01-26
It's been close to a year and no bite marks.
EHL
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Wednesday, January 26, 2011 6:13 AM
> To: Marius Scurtescu
> Cc: Eran Hammer-Lahav; oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> 2. Section 8.2. What about applications using legacy parameters? Does
> not make much sense to register them, and they cannot be changed to
> x_.
I *guarantee* that there will be many noncompliant implementations of
this, built on server frameworks with required parameters on all
endpoints. Not
I plan to publish a quick fix to editorial issues raised in a -13 on Monday
1/31. If you have editorial feedback, please post it to the list by Friday 1/28
so that I can respond and incorporate if needed. This is not a deadline for
normative issues, only editorial, but you can post feedback on b
Hi Brian,
you identified the use cases correctly. No interactive user-consent would be
required.
Regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland
-Original Message-
From: Brian Eaton
Date: Tue, 25 Jan 2011 09:53:20
To: Torsten Lodderstedt
Cc: Eran Hammer-La
Thanks William.
It is important to differentiate between style and substance (both of which are
very important to people).
Style-wise, we can use either of the three options below, but they are
essentially the same. You take the string and put it through a parser and end
up with the actual sch
37 matches
Mail list logo
