is
half of OAuth 1.0, one I proposed, and one James proposed. The last
two have not built a community just yet...
Our goal is to come up with a single protocol, and I need to work on
a single draft by collecting feedback and incorporating it.
EHL
-Original Message-
From: Anthony
choose a
strating point.
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Wednesday, February 17, 2010 10:13 PM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Proposed agenda for third interim meeting
I don't know why you feel like I am
My design principles would be the following as we already have protocols that
solve many complex usecases
1. Simple programming model
3. Reduce deployment barriers
2. Limited or no client side code (works with a browser)
3. Replace username/password scenarios
4. No client side key
Why is the native application launching a browser with a protected resource
request? That seems odd.
Not odd at all a lot of the Eclipse applications can work this way
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Thursday, April 08, 2010
I would actually like to see the inclusion of reference tokens here also, I do
think that the 255 character limit is too restrictive and needs to be revisited.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Eaton
Sent: Friday, April
I'm strongly opposed to writing a spec that must be profiled in order to be
implemented and the proposed definition of the scope parameter mandates
profiling the spec.
I'm strongly opposed to having a specification that can't be used because it's
so restrictive
From: oauth-boun...@ietf.org
It would be useful to understand the token type as the AS and RS server may
each generate and accept different token types
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Andrew Arnott
Sent: Friday, June 04, 2010 6:43 AM
To: George Fletcher
Cc: OAuth WG
confirmations.
On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin tony...@microsoft.com wrote:
There are many cases where we need to have more than 1 SAML assertion be used
to represent the authorization token, so would want a provision for multiple
SAML tokens and not sure it makes sense to have
Seems that ISO/IEC 24760 is yet another one that does not align with
Recommendation X.1252 (IdM terms)
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor
Faynberg
Sent: Wednesday, August 11, 2010 10:42 AM
To: Tschofenig, Hannes (NSN -
So the UK Government Gateway project is a concrete use case. The use case for
the UK government is that the government has many assertion providers; this is
due to both legal and historical reasons. The first assertion provider is UK
Department of Works and Pension (DWP), the second one is
tokens,,
this winds up being more complicated and traffic, the reason to not send
directly is for user consent.
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Friday, August 20, 2010 11:29 AM
To: Anthony Nadalin
Cc: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell; oauth
So we have been working with Nat on the signature proposal and talking to Nat
he agrees that the JWT proposal is well under way, what I would like to make
sure is that we merged in with your proposal
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dirk
Balfanz
Sent:
What is needed is needed is the security considerations section complete, I
don't think that the signature specification has to be in the core to be
complete, there are previsions to use SSL, if one needs to go beyond this then
a reference to the signature specification would be in the security
Not seeing an overwhelming support for doing this, how many interoperable
deployments of 1.0a signature are there?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Sunday, September 26, 2010 11:44 PM
To: OAuth WG (oauth@ietf.org)
Subject:
Still no real answers ...
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Monday, September 27, 2010 9:46 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: RE: Proposal: OAuth 1.0 signature in core with revision
You must be joking about 1.0a signature deployment. It's also
So this one I do feel more strongly about: We should only include crypto
mechanisms that everybody MUST support. Otherwise, we'll have to invent some
sort of negotiation step in the protocol: do you support alg XYZ? No I
don't, please use ABC. Let's not do that.
As just one datapoint,
...@google.com]
Sent: Friday, October 01, 2010 8:45 PM
To: Yaron Goland
Cc: Anthony Nadalin; Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts
On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland
yar...@microsoft.commailto:yar...@microsoft.com wrote:
No matter what algorithm or key
: Wednesday, October 06, 2010 2:26 PM
To: Anthony Nadalin
Cc: Yaron Goland; Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts
So what's the proposal, then? That OAuth service providers document what crypto
mechanisms they support? And developers will just have to know
It has been quiet here, so
1. Did we get agreement to the document split (assume so as I did not see
any negatives), if so when can we expect draft 11 or the core and the 1st draft
of the new document?
2. Did we get editor(s) assigned to the new document?
3. Will there be a
correlation unless the user decides to permit
discovery.
The model if not the details seem similar to some work that is being submitted
to the ITU-T as I understand it.
John B.
On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote:
Sampo, can you give a usecase of how you would use the pairwise
Can't really comment on product futures but Messenger Connect already has WRAP
support and ACS has Oauth 2.0 v10 support but there seems to be a trend here
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of hank
williams
Sent: Friday, October
: John Bradley [mailto:jbrad...@mac.com]
Sent: Thursday, October 28, 2010 5:22 PM
To: Anthony Nadalin
Cc: the Connect work group; sa...@zxidp.org; openid-specs...@lists.openid.net;
oauth@ietf.org
Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery
If there is no authorization mechanism
Like an XML parser
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Friday, October 29, 2010 9:24 AM
To: Anthony Nadalin; John Bradley
Cc: sa...@zxidp.org; openid-specs...@lists.openid.net; the Connect work group;
oauth@ietf.org
Subject: RE: [OAUTH-WG
I was looking for less of an analysis and more of considerations (of the
current flows and actors), I'm not sure how to adapt what you have done to
actually fit in the current specification, was your thought that you would
produce a separate security analysis document?
-Original
Cc: Anthony Nadalin; Tschofenig, Hannes; ab...@ietf.org; r...@ietf.org;
i...@ietf.org; sec...@ietf.org; web...@ietf.org; x...@ietf.org;
kit...@ietf.org; i...@iab.org Board; i...@ietf.org; oauth@ietf.org
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial OAuth Security Session **
I would say
Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Tuesday, November 09, 2010 11:14 PM
To: oauth@ietf.org
Cc: Nicolas Williams; Anthony Nadalin; Tschofenig, Hannes
Subject: Re: [kitten] [OAUTH-WG] ** OAuth Tutorial OAuth Security Session **
Am 10.11.2010 08:00, schrieb
Concern here is that HTTP Basic Auth provides a straightforward interop profile
for the web server profile
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Richer, Justin P.
Sent: Monday, January 17, 2011 7:43 AM
To: Eran Hammer-Lahav; OAuth
If it is left as optional (not removed) then I'm OK to go with parameter-based
approach as default
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Tuesday, January 18, 2011 9:50 AM
To: Anthony Nadalin; Richer, Justin P.; OAuth WG
Subject: RE: [OAUTH-WG
We should then have a consensus call to remove items like this
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Friday, January 21, 2011 11:11 AM
To: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D
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,
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
, 2011 5:38 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: Removal: Client Assertion Credentials
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
to drop it is just
poor practice.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Tuesday, January 25, 2011 6:11 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Removal: Client Assertion Credentials
Scope was discussed in detail, including use cases and implementation
: Wednesday, January 26, 2011 2:51 PM
To: Anthony Nadalin
Cc: OAuth WG
Subject: RE: Removal: Client Assertion Credentials
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
There have been several of us that have objected and several of that have
implemented this feature, it's late in the cycle to remove, so I raise the
objection.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Thursday,
#1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Tuesday, February 08, 2011 3:05 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Bearer token scheme name - new vote deadline Sat, 2/12
Given that people are clearly voting to change the bearer token scheme
Nice job Phil
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil
Hunt
Sent: Monday, February 21, 2011 4:46 PM
To: OAuth WG
Subject: [OAUTH-WG] Flowchart for legs of OAuth
FYI. I published a blog post with a flow-chart explaining the legs of
Torsten, Mike Jones and I will be there all week, it might be good to setup
some time to go through the Security Considerations draft
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Friday, March 11, 2011 1:15 AM
To:
Why the early cut-off date? As this is in advance of IETF 80, changes will
wait until after Prague in any case.
To inform the discussions @ IETF 80 to determine what else might be needed,
which goes to your second comment
-Original Message-
From: oauth-boun...@ietf.org
My preference would be option A
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Friday, March 11, 2011 3:04 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday,
March 18
As you know, the OAuth 2.0 Bearer
I think it does for example how one might discover the authorization service
and this would be a forum to see if others also do or not.
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, March 17, 2011 11:56 AM
To: Anthony Nadalin; Hannes Tschofenig
...@hueniverse.com]
Sent: Thursday, March 17, 2011 3:58 PM
To: Anthony Nadalin; Hannes Tschofenig; oauth@ietf.org
Subject: RE: [OAUTH-WG] Agenda Proposal
This proposal goes far beyond just solving any discovery needs for OAuth. It
also directly competes with existing (deployed) proposals. This group
Will do as I think the system opens back up on the 28th
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Friday, March 18, 2011 11:22 AM
To: Anthony Nadalin
Cc: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Agenda Proposal
Hi Tony,
please
Anthony Nadalin
For D or C:
Eran Hammer-Lahav
William Mills
Given that twice as many people indicated a preference for A as for any other
option, that seems to indicate a consensus for A. Therefore Eran, when you
update your draft, can you please
is that some folks feel that we will ever have any OAuth
Extensions and anything that extends OAuth can do whatever it likes and we
don't want to have any conventions dictated by the base.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Tuesday, March 22, 2011 9:52 PM
To: Anthony Nadalin
OAuth issues security tokens without indicating where they can be safely
used. While that fatal flaw remains, it is pointless to specify the use of
the Origin header.
I don't think anything should be in the base as the different token profiles
can stipulate the audience.
From:
I also object, an error registry the proper approach here.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Thursday, March 31, 2011 11:31 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Error extensibility proposal
way?
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, March 31, 2011 2:43 PM
To: Anthony Nadalin; Mike Jones; OAuth WG
Subject: RE: Error extensibility proposal
'PROPER' REQUIRES USE CASES AND REQUIREMENTS!
You have to show how the proposal does
I completely agree with you regarding not being able to authenticate a native
client.
I suggest you read the security considerations draft to make sure this is
correct and points out the issues
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
3.3 Client Assertion Credentials. OAuth2 currently supports the concept of a
client app swapping an assertion for an access token. Do people want the
additional functionality of using assertions for generic client
authentication? I assumed servers would prefer that clients swap an assertion
that Thomas has resurrected is just fine and I
would support getting that text back into the document.
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Monday, April 18, 2011 3:46 PM
To: Anthony Nadalin; Manger, James H; oauth
Subject: RE: Revised Section 3
, 2011 4:10 PM
To: Anthony Nadalin; Manger, James H; oauth
Subject: RE: Revised Section 3
I don't think you understand what 'breaking' means. Breaking would be if we
assigned a different meaning or syntax to the two parameters, or changed their
name. Breaking requires code changes
...@hueniverse.com]
Sent: Monday, April 18, 2011 4:24 PM
To: Anthony Nadalin; Manger, James H; oauth
Subject: RE: Revised Section 3
At least I finally got you to agree that this can be done in a separate
specification. That's progress.
EHL
-Original Message-
From: Anthony Nadalin
:06 PM
To: Eran Hammer-Lahav; Anthony Nadalin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
Resolves *my* confusion. :)
Tony: apologies if you covered this in earlier posts, but if 4.5 does not solve
your use case, would you clarify what else is needed? Are you unhappy that it
is labeled
Some additional input
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, April 21, 2011 12:28 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
This got a little bit too nested so I kept only the comments where we are not
on the same
]
Sent: Friday, April 22, 2011 3:25 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Fri, 22 Apr 2011 14:51:33 -0700
AJN- So the client credentials originate from WRAP also, it's
case with
additional text. If you want to come on site you can see the code and the dates
on the code that predates Yaron's text.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Friday, April 22, 2011 3:40 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised
There is no extension in WRAP to allow this, it’s allowed as part of WRAP.
From: William J. Mills [mailto:wmi...@yahoo-inc.com]
Sent: Friday, April 22, 2011 4:10 PM
To: Anthony Nadalin; Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
That WRAP allowed
I think that a re-charter after would be a great idea
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Monday, May 09, 2011 4:17 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org; oauth-...@tools.ietf.org
Subject: Re:
-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Wednesday, May 25, 2011 6:54 AM
To: Anthony Nadalin
Cc: oauth
Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1
subsection on assertions
That is another way to approach it and I understand there has been some talk
...@pingidentity.com]
Sent: Wednesday, May 25, 2011 12:22 PM
To: Anthony Nadalin
Cc: oauth
Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1
subsection on assertions
It's not exactly clear to me what that means.
Near the end of the interim meeting on Monday there was a specific discussion
The OAuth spec is somewhat silent about how a resource provider should perform
a redirect as there are many ways to accomplish the redirect. We also
discovered that since the HTTP specifications were somewhat vague on fragments
that some HTTP client implementations strip the fragment, we have
Since Torsten and I had the action item to propose text we will update the text
based upon the list and give you back an update
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Wednesday, June 15, 2011 9:33 AM
To: Chuck Mortimore; oauth@ietf.org
This also moves the client_credentials authentication material out of the core
and into a core companion specification.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Saturday, June 18, 2011 1:08 PM
To: Chuck Mortimore; oauth@ietf.org
Subject: Re:
9. Native Applications
A native application is a client which is installed and executes on the
end-user's device (i.e. desktop application, native mobile application, etc.).
Native applications may require special consideration related to security,
platform capabilities, and overall end-user
[mailto:bea...@google.com]
Sent: Thursday, July 07, 2011 10:59 AM
To: Anthony Nadalin
Cc: Eran Hammer-Lahav; oauth@ietf.org; Mark Mcgloin (mark.mcgl...@ie.ibm.com);
Torsten Lodderstedt (tors...@lodderstedt.net); Phil Hunt (phil.h...@oracle.com)
Subject: Re: [OAUTH-WG] security considerations
Section 3.1.2 explicitly states that the redirection endpoint URI MUST be an
absolute URI. But that means that the URI could be potentially of any scheme.
This is probably intentional since there are scenarios where a native client
will want to register a custom scheme as the call back URI.
Nowhere in the specification is there explanation for refresh tokens, The
reason that the Refresh token was introduced was for anonymity. The scenario is
that a client asks the user for access. The user wants to grant the access but
not tell the client the user's identity. By issuing the
Many reasons, but none are explained in the specification
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
My recollection of refresh tokens was for security
Anonymity was certainly part of the design for WRAP
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
Section 1.5 already covers refresh tokens
Section 1.5 does not explain why refresh tokens are there. If implementers
don't understand why we did something then how are they supposed to get the
implementation right?
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick
Could be! But a definite from Yaron.
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, August 11, 2011 1:25 PM
To: Anthony Nadalin
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
If it was, no one told me.
On 2011-08-11, at 12:41 PM, Anthony
There are no use cases at all in WRAP to help explain choices taken, it does
not matter if there were or were not previous issues raised, it is being raised
now.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc
I’m raising the issue on the current text, I already provided text if the
original append.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
1. Process
Disagree, this was our rational and this is one way it’s used today with our
scenarios. This needs to be assigned an issue.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 3:39 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re
MUST confirm that
returned value of the state parameter matches the value stored with
the resource owner's user-agent.
EHL
From: Torsten Lodderstedt tors...@lodderstedt.net
Date: Fri, 12 Aug 2011 23:58:02 -0700
To: Eran Hammer-lahav e...@hueniverse.com
Cc: Anthony Nadalin tony
Agree, against the removal of text
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Lodderstedt, Torsten
Sent: Thursday, August 18, 2011 1:01 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Partial set of last call comments on
Concern here is we have a protocol that is open to attacks, we need to document
a way that developers can safely implement, leaving it up to the developer may
not be the best way unless they know what they are doing, so more in favor of
recommending the use of state and if the developer can do
: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
This is really just a flavor of CSRF attacks. I have no objections to better
documenting it (though I feel the current text is already sufficient), but we
Acceptable, but not ideal
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Sunday, September 04, 2011 4:20 PM
To: William J. Mills; Anthony Nadalin; Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Auth Code Swap Attack
This is my
If scoped right I don't see any issues with any of these proposed items fitting
into this WG, the question will be do we have the band width to work on all
these items, as some are big and some are fairly small and contained. May have
to have some prioritized list of where people think these
Could be 2 tokens that still fulfill the same scope just that each token is a
subset of the requested scope.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Monday, October 31, 2011 2:17 PM
To: Dick Hardt
Cc: OAuth WG;
I would agree as we ran into this from some of deployment we had. What is the
driving factor here for 1.2 over 1.0?
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Rob
Richards
Sent: Thursday, November 17, 2011 3:07 AM
To: Barry Leiba
Cc:
Making the draft-ietf-oauth-v2-bearer mandatory to implement gets us a bearer
(unknown content and format) token from the authorization server, for the
resource server this gets us a authentication scheme of bearer (unknown content
and format) token, not sure where this gets us towards interop
And if the servers don't implement the should on 1.0 how do we get
deployments for the other actors that can't talk to 1.2
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Barry
Leiba
Sent: Thursday, November 17, 2011 3:19 AM
To: Rob Richards
I agree we have no plans to implement MAC if we wanted that we would have been
happy with OAUTH 1.0a but that was not deployable
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Saturday, December 03, 2011 6:26 PM
To: Barry
Not really sure how you came to the conclusion that native mobile clients can't
be confidential? As pointed out in section 3.7 of the
http://www.ietf.org/id/draft-ietf-oauth-v2-threatmodel-01.txt there are
guidelines that confidential clients should follow, but does not distinguish
between
Agree contents looks good
Sent from my Windows Phone
From: Igor Faynberg
Sent: 3/14/2012 4:26 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
Looks good and comprehensive to me.
Igor
On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:
So, here
Why rant here, talk to the chairs or AD
Sent from my Windows Phone
From: Eran Hammer
Sent: 6/8/2012 6:58 PM
To: oauth@ietf.org WG (oauth@ietf.org)
Subject: [OAUTH-WG] New draft process / editor role
Today, a new draft of the OAuth 2.0 specification was published.
Not sure why this has to be a MUST in section 3.2.1 as the token endpoint has
to the choice to reject it either way (provided or not)
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John
Bradley
Sent: Sunday, July 01, 2012 2:22 PM
To: oauth@ietf.org WG
Subject:
While the client may be forced to provide the client_id there are no
requirements for the endpoint to process the client_id (or how that is done) so
not sure what good the change actually does
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday,
I read 4.1.3 as the client_id just has to have been issued to a (or any)
public client
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Monday, July 02, 2012 2:54 PM
To: Anthony Nadalin
Cc: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 4.1.3
The change
Hannes, thanks for drafting this, couple of comments:
1. HOK is one of Proof of Possession methods, should we consider others?
2. This seems just to handle asymmetric keys, need to also handle symmetric keys
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
also be interested in
key establishment methods as well
When I say arguably, I expect you to argue.
John B.
Sent from my iPhone
On 2012-07-10, at 1:01 PM, Anthony Nadalin
tony...@microsoft.commailto:tony...@microsoft.com wrote:
Binding the key to the channel is arguably the most
I will not be at CIS
Sent from my Windows Phone
From: John Bradley
Sent: 7/15/2012 10:59 AM
To: Phil Hunt
Cc: Anthony Nadalin; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested
Good working with you and Tony
You providing beer?
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Monday, July 30, 2012 9:33 AM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Informal OAuth Chat @ IETF#84
Hi all,
for those who are attending the IETF
I think that there is also the Proof Key observation for Proof of Possession
that needs to be included:
When creating response, the AS encrypts both the token and the proof key within
it using the public key of the RS. The AS also includes the proof key in the
response and encrypts it using
I agree that HOK may be independent of MAC and should be a separate issue, as
MAC does not solve my proof of possession for a HOK solution
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
William Mills
Sent: Monday, November 26, 2012 10:42 AM
To: Phil Hunt; Sergey
It seems premature and we should consider this in the bigger context of the on
behalf of/delegation work that has been started
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat
Sakimura
Sent: Tuesday, December 18, 2012 6:22 PM
To: oauth
Subject: [OAUTH-WG] cid claim
I can't see how you think PRN is way under defined when SUB is not
From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Wednesday, December 19, 2012 11:43 PM
To: Mike Jones
Cc: Anthony Nadalin; John Bradley; oauth
Subject: Re: [OAUTH-WG] cid claim in JWT
As prn is way under-defined [1
1 - 100 of 246 matches
Mail list logo
