Back to Marius' question though, which is about how we determine how to treat
the Authenticate header when you see it. I, for one, was not happy with the
way that Wrap added on to the OAuth scheme. There are at least 3 possibilities
that it seems to be worth discussing:
1) a fixed scheme name
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-ietf-oauth-v2-12.txt
>
> On Thu, Jan 20, 2011 at 9:41 PM, Eran Hamm
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Tuesday, January 25, 2011 12:23 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: RE: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with
> tokensendpoint?
>
> Zitat von Eran Hammer-Lahav :
>
Thanks Phil.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Phil Hunt
> Sent: Sunday, January 23, 2011 12:23 PM
> To: oauth@ietf.org WG
> Subject: [OAUTH-WG] Draft 12 - Protocol flow not clear yet
>
> Section 4 seems to inter-mixes obtai
Since you are a recent addition to the working group, you probably don't know
that I objected to using both the OAuth and OAuth2 scheme names and wanted to
call the scheme name Token. Producing a generally applicable HTTP
authentication scheme is actually in our original charter and was one of t
I found this in my archives as an open question. Can someone please review
Tim's note and address the security considerations it contains?
EHL
> -Original Message-
> From: Freeman, Tim [mailto:tim.free...@hp.com]
> Sent: Tuesday, September 14, 2010 11:03 AM
> To: Eran Hammer-Lahav; Torst
To the extent that the OAuth2 protocols are intended to provide an end-to-end
solution, the more consistency the better, hence the "OAuth2" name. Since the
same feature used the "OAuth" name in draft 10 (which you authored), I find it
hard to take seriously your objections to the "OAuth2" name
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 a scheme with sub-schemes but that idea was strongly rejected (over
Also it's possible that extensions will define an authentication scheme which
is available through Oauth2 and also through other pathways. It might be you
can obtain a MAC token through a flow other than OAuth.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ie
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
about going with OAuth2 and some kind of token_type.
Logically
On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones
wrote:
> I’d like a sense from the working group whether others want this change, and
> if so, what the name should be changed to.
Probably this was debated, but I will ask again.
Why can't we use "OAuth2" as the scheme in all cases and require a
toke
Scope was discussed in detail, including use cases and implementation
experience and the current language was (painfully) negotiated to reach a
balance between flexibility and library interoperability. Client password
authentication is well understood, is the primary way API calls are
authentic
Can you share with the list how you plan to use this client assertion
authentication scheme?
Which of the authorization grant types you will use it with?
Will you use it with the authorization endpoint, and if so, how will you bind
the assertion to the client_id?
Can you provide full examples of
Based on your logic then Scope, Client Password Authentication, etc, should be
removed. Not sure how leaving the proposed text in would delay things
From: David Recordon [mailto:record...@gmail.com]
Sent: Tuesday, January 25, 2011 5:11 PM
To: Anthony Nadalin; hannes.tschofe...@gmx.net; Eran Hamme
Explicitly saying, "The assertion format, the process by which the assertion
is obtained, and the method of validating the assertion are defined by the
assertion issuer and the authorization server, and are beyond the scope of
this specification" seems to reinforce the point about this being
unders
On Thu, Jan 20, 2011 at 9:41 PM, Eran Hammer-Lahav wrote:
> Forgot to mention that I don't have any outstanding comments in my queue so
> if your feedback was not incorporated into -12, and you feel strongly about
> it, bring it up again.
>From an older email, adapted to v12:
1. The token_typ
I don't understand the rationale for removing the client assertion credentials,
as client password authentication is left in. Client Password Authentication is
also underspecified as client_secret could be anything that the authentication
server seems fit (raw clear text password, hash, digest,
Hey Torsten -
I'm trying to parse through these messages to figure out the flows
you're interested in.
I think you're aiming for rules like this one, right?
kerberos authentication -> access token
or
digest authentication -> access token
And furthermore your intended use cases are applica
Torsten is looking to supplement/replace the Resource Owner Password
Credentials grant with similar constructs but using existing user password
frameworks. This has nothing to do with actual user interactions and the
authorization endpoint.
EHL
From: pathoge...@gmail.com [mailto:pathoge...@gma
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.
Why, then, would you want to integrate existing
Zitat von Eran Hammer-Lahav :
There is no clean way to do with without defining new HTTP
authentication schemes. The token endpoints takes:
1. Client authentication
2. Authorization grant
There is no user authentication. Even the resource owner password
credentials is not user authenticati
21 matches
Mail list logo
