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
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
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
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;
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. There
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 and
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 refresh
The spec states in multiple places that servers control how big authorization
and other codes are so clients can't be sure how much space they will have in
URIs. How can anyone design a client that is intended to work with multiple
authorization servers if they have no clue how big their state c
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.
[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
When we constructed the current structure in Prague we thought that structure
best fit the needs of a implementer, so my preference would be to keep it as it
is now but, Torsten / Mark / Phil also may have feedback.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ie
28, 2011 6:36 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Native Application Text
You text does not mention what will be a common use case, where the native app
uses the password grant to fetch a refresh and access token. Whether or not an
app can keep a secret
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 e
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: [OAU
text as there is not
consensus to do that, since there was an action item to put text back in.
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Wednesday, June 15, 2011 10:19 AM
To: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org
Subject: RE: Updated text for Native Apps
This working
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
S
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 th
...@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 discu
-
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
I think that this will be better moved into a separate document on assertions
(were both authorization and authentication are talked about) and not to
include in 4.5.1 but would like to see a reference in 4.5.1 to the new document
-Original Message-
From: oauth-boun...@ietf.org [mailto:o
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: [OAUTH-WG
I propose that we close issue #12 (Restore WWW-Authenticate response to the
framework specification) with no action, that is each extension would handle as
they are doing now.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Barry
Leiba
Sent:
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
e use 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-W
e.com]
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 mailto:tony...@microsoft.com>>
Date: Fri, 22 Apr 2011 14:51:33 -0700
AJN-> So the client credentials originate from WRAP also, it&#x
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
Clarifications
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Wednesday, April 20, 2011 4:52 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
I had a hard time following some of this but I'll try to clarify.
From: Anthony Nadalin mailto
ay, April 19, 2011 2: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
...@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: Anth
: Monday, April 18, 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 r
continue
to say. I think that the text 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, Jame
>"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 asserti
> 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
So the rewrite of the text was given to Torsten and myself as action items, but
welcome others to help out here
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Monday, April 04, 2011 12:06 PM
To: Skylar Woodward; Marius Scurte
This section makes sense as it does setup for the identification and
authentication of the client, so I do believe that it makes sense in the
document. Thomas undertook the task to revive the Client Credentials section
from previous draft that will include normative text, which when asked the r
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 pro
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
> 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: oauth-boun
Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Wednesday, March 23, 2011 3:30 PM
To: Anthony Nadalin; Phil Hunt; Manger, James H
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] Apparent consensus on OAuth Errors Registry
> -Original Message-
> From: Anthony Nadalin [mailto:tony...@m
What I'm hearing 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, 20
in the poll I conducted on the OAuth Errors Registry:
For A:
Mike Jones
Igor Faynberg
Justin Richter
Anthony Nadalin
For D or C:
Eran Hammer-Lahav
William Mills
Given that twice as many people indicated a preference for
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
...@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 is not
the
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
Is it possible to add these to the mix?
http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt
and also the http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-00.txt
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tsch
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 T
> 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 [mailto:oauth-
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:
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
#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 na
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,
: 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
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
, 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
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
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,
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 Action:draft-iet
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: [OAU
I also support option #1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Campbell
Sent: Sunday, January 16, 2011 7:29 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote
by 1/17
I guess I'm in the minority but I prefer
Agree that these would be code breaking changes and cause interoperability
issues late in the specification cycle
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Tuesday, January 18, 2011 9:36 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: [OAUTH-
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 WG
--Original 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
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
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 Message
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
: 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
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 29
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 pairw
Sampo, can you give a usecase of how you would use the pairwise
-Original Message-
From: openid-specs-ab-boun...@lists.openid.net
[mailto:openid-specs-ab-boun...@lists.openid.net] On Behalf Of sa...@zxidp.org
Sent: Tuesday, October 26, 2010 6:40 PM
To: Mike Jones
Cc: sa...@zxidp.org; open
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
: 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
:balf...@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
mailto:yar...@microsoft.com>> wrote:
No matter what algorithm or key size
> 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 datapoi
I agree bearer tokens are already in wide usage, I think it makes sense to have
a default interoperable token type, much like a token format and signature. The
security considerations section can point/cover any issues.
I'm not seeing what the splitting of the document is achieving except side
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
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: [OAUTH-W
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
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: Mo
I have not seen the support to bring signature support back into core, have not
seen the public response either, all I have seen is you raising this as an
issue. We should keep the original agreement to move signatures out of core,
there is enough activity on signatures that we are confident tha
Eric, Microsoft shares some of the same views, we would like to see the WG
charter expanded to cover these additional items (so we have a home for these),
we would like to see that proposed and agreed upon at the November meeting if
at all possible.
From: oauth-boun...@ietf.org [mailto:oauth-bo
Might actually want both @ same time, so might be better to expand
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of hdknr
hidelafoglia
Sent: Tuesday, September 21, 2010 12:39 PM
To: Yaron Goland
Cc: oauth
Subject: Re: [OAUTH-WG] OAuth Signature
Using the native client would be one way to acquire the user consent.
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Tuesday, August 31, 2010 12:36 AM
To: Anthony Nadalin
Cc: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell; oauth
Subject: Re: [OAUTH-WG] more than one
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
: Friday, August 20, 2010 2:11 PM
To: Anthony Nadalin; Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] more than one assertion?
This is a convincing use in support of the multiple assertions.
My understanding is that in the use case the two assertions provide the
ameters sent without
> a value MUST be treated as if they were omitted from the request. The
> authorization server SHOULD ignore unrecognized request parameters."?
>
> That said, does it make sense to relax the ban on repeating parameters in
> some situations, like for the a
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 - FI/E
[mailto:bcampb...@pingidentity.com]
Sent: Tuesday, August 03, 2010 1:12 PM
To: Anthony Nadalin
Cc: oauth
Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft
Seems like a much more complicated scenario. Allowing more than one assertion,
off the top of my head, would necessitate
ultiple subject confirmations.
On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin 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
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 a separate profile for that or
add it as an option here.
-Original Message-
From: oa
> If a server needs to verify, it can literally iterate over all of the keys
> associated with the client until it finds the right one.
Depends on how the server stored the keys, this can be a very expensive
operation w/o a key_id to match/index on
-Original Message-
From: oauth-boun...
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 (oauth@ietf.org)
> 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.o
+1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Friday, April 09, 2010 11:57 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Defining a maximum token length?
+1 no restriction, please
256 is much too short
Am 10.04.2010 07:16
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 09,
> 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'm not sure if you are coming from the user or service perspective. So if a
user asks for HTTPS do you have to support HTTPS? If a service asks for HTTPS
do you have to support it? Or do you just fail?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Allen
Tom
Sent: T
So I doubt that the client always knows what the server supports, the server
should be open in allowing all parties to find out what is supported
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Eaton
Sent: Tuesday, March 30, 2010 5:44 PM
Yes the flows are interesting and we would be willing to work on them
-Original Message-
From: Chuck Mortimore [mailto:cmortim...@salesforce.com]
Sent: Wednesday, March 24, 2010 9:11 AM
To: Anthony Nadalin; David Recordon; Torsten Lodderstedt; Mark Mcgloin
Cc: OAuth WG
Subject: RE
I don't think that Microsoft ever indicated that we need the SAML flows.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Recordon
Sent: Tuesday, March 23, 2010 10:48 AM
To: Torsten Lodderstedt; Chuck Mortimore; Mark Mcgloin
Cc: OAuth WG
S
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 distributio
201 - 300 of 308 matches
Mail list logo
