In this version the example URLs have been changed as suggested in
http://www.ietf.org/mail-archive/web/oauth/current/msg09978.html .
There are no other changes.
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.or
Thank you, Barry and Mike:
I will make changes for the next version.
Zachary
-Original Message-
From: barryleiba.mailing.li...@gmail.com
[mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba
Sent: Wednesday, October 10, 2012 12:46 PM
To: Zeltsan, Zachary (Zachary)
Cc
not necessarily belong to the same organization, is not sufficient
(according to some readers). How to avoid the confusion?
Zachary
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Wednesday, October 10, 2012 11:46 AM
To: Zeltsan, Zachary (Zachary
+1
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil
Hunt
Sent: Saturday, October 06, 2012 2:54 PM
To: Torsten Lodderstedt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting
+1
Phil
On 2012-10-06, at 10:07,
Adam,
Thanks. The use case is clear now.
Zachary
From: Lewis Adam-CAL022 [mailto:adam.le...@motorolasolutions.com]
Sent: Tuesday, September 18, 2012 12:25 PM
To: Zeltsan, Zachary (Zachary); oauth@ietf.org
Subject: RE: [OAUTH-WG] prompt parameter for Authorization Request
Hi Zachary,
Your
Adam,
In your use case, how does AS request user re-authentication?
In OAuth the user agent is redirected back to the Client after the user has
authorized the client.
The AS is a web server and cannot initiate a call to the user agent. I assume
that the request to re-authenticate comes in a resp
Hannes,
Thank you for the review and comments. My responses (which start with Z:) are
below.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Friday, June 22, 2012 3:08 AM
To: oauth@ietf.org WG (oauth@ietf.org)
Subject:
Hannes,
I plan to attend the meeting and present on the status of the draft
draft-ietf-oauth-use-cases.
Zachary
- Original Message -
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Saturday, June 02, 2012 02:46 AM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Meeting slot
x27;s signature in order
to verify the Issuer of the assertion.
Zachary
From: Chuck Mortimore [mailto:cmortim...@salesforce.com]
Sent: Friday, April 13, 2012 1:20 PM
To: Zeltsan, Zachary (Zachary); Tschofenig, Hannes (NSN - FI/Espoo);
oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC on Assertion D
-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Friday, April 13, 2012 1:33 PM
To: Zeltsan, Zachary (Zachary)
Cc: tors...@lodderstedt.net; gffle...@aol.com
Subject: New Version Notification for draft-zeltsan-oauth-use-cases-03.txt
A new version of I-D, draft-zeltsan-oauth-use-cases-03.txt
Hello,
The draft http://tools.ietf.org/html/draft-ietf-oauth-assertions-01, section
6.1 has the following requirement:
The Authorization Server MUST validate the assertion in order to
establish a mapping between the Issuer and the secret used to generate
the assertion.
I thought that che
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Wednesday, March 14, 2012 4:55 PM
To: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
... Considering OpenID Connect as a motivating use case for OAuth, SWD is the
one
David,
A use case that is similar to yours is described in
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02, section 3.8.
OAuth 2.0 does not directly support this use case.
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf O
beryoz...@gmail.com]
Sent: Thursday, March 01, 2012 5:17 PM
To: Zeltsan, Zachary (Zachary)
Cc: 'Richer, Justin P.'; ''
Subject: Re: [OAUTH-WG] Few questions about client_credentials
Hi,
On 01/03/12 19:23, Zeltsan, Zachary (Zachary) wrote:
> In the case of the Client Creden
In the case of the Client Credentials Grant, an authorization servers knows
what resources the client is authorized to access (this includes the resources
that are not owned by the client). The specification explains that
authorization of access to the resources "has been previously arranged wit
The user authentication and access control to the resources is out of the OAuth
scope.
The question is how to make a resource (e.g., a photo) accessible by the
authorized clients C1,...,Cn. If each client has obtained a user's
authorization for the scopes that include the photo, then all client
BEAST is an attack against TLS 1.0. In order to succeed, an attacker,
predicting that a user will eventually make an https connection to
www.example.com, lures the user to an attacker-controlled web site. From that
site the user browser downloads the attacker's script (e.g., JavaScript). Then,
I agree with Torsten that there is a need for supporting the multiple tokens
use case.
Such a use case is described in the OAuth 2.0 use cases draft
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.10
Zachary
From: oauth-boun...@ietf.org
There is a requirement in the core specification (Section "6 Refreshing an
Access Token) that authorization server "MUST verify that the resource owner's
authorization is still valid" when issuing an access token in exchange for a
refresh token. How is such verification done (given that authori
the client.
How authorization server can validate the client's identifier before
authenticating the client?
Zachary
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, June 16, 2011 1:52 PM
To: Zeltsan, Zachary (Zachary); 'Loddersted
I agree with the statement. Authorization server provides information about a
client to a user based on the client's identifier, which client has presented
to the server. If authorization server cannot validate the client's identity
claim, it must make the user aware.
__
I agree with Brian.
One of the use cases that relies on the issuing tokens to an unauthenticated
client is Mobile App
(http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-01#section-3.4). A
use case's requirement is that "authorization shall be valid for a prolonged
duration". Such long-te
Melinda,
My comments are inline.
With thanks,
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Melinda Shore
Sent: Tuesday, April 19, 2011 7:29 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Use cases document review
At the oauth session a
Melinda,
Thank you for the review and feedback.
We (the co-authors) have also received comments on the draft from Thomas
(copied).
I plan to address all comments and respond by the end of the next week.
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf
I have been involved with MARF WG, which Barry co-Chairs, and am sure that this
appointment is a good news for OAUTH.
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Stephen Farrell
Sent: Wednesday, April 13, 2011 3:10 PM
To: oauth@ie
1:15 AM
To: Skylar Woodward
Cc: Zeltsan, Zachary (Zachary); Kris Selden; oauth@ietf.org
Subject: AW: Re: [OAUTH-WG] Flowchart for legs of OAuth
Hi Skylar,
Thank you for sharing this information with us. Some thougts:
The empty string makes your implementation syntactically compliant but does
odified, it is not useful for the native applications.
Regards,
Zachary
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, April 04, 2011 5:01 PM
To: Zeltsan, Zachary (Zachary)
Cc: 'Marius Scurtescu'; Kris Selden; oauth@ietf.org
Su
According to section "6 Refreshing an Access Token" (-13.txt), client when
making a request for exchanging a refresh token for an access token has to
include its authentication credentials, and the "authorization server MUST
validate the client credentials".
How can this be done if a client is
The spelling of the name "Bearer" authentication scheme in the draft is
inconsistent with the spelling in
draft-ietf-oauth-v2-bearer-03.
In draft-ietf-oauth-v2-13, section 7.1:
"For example, the "bearer" token type defined...",
and
"Authorization: BEARER h480djs93hd8"
In draft-ietf-oauth-v2-bea
Torsten,
I will attend the IETF 80 starting on Monday.
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Friday, March 11, 2011 4:15 AM
To: OAuth WG
Subject: [OAUTH-WG] IETF-80
Hi all,
who of the WG will att
I posted a new version of the draft on the OAuth use cases today.
Your comments are welcome.
Zachary
-Original Message-
From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org]
Sent: Friday, February 04, 2011 4:44 PM
To: Zeltsan, Zachary (Zachary)
Cc: gffle...@aol.com; tors
can see confidential
data (in which case use TLS), or can block execution. It cannot do anything
other than what the client was trying to do, as-is.
EHL
On 1/12/11 11:46 AM, "Zeltsan, Zachary (Zachary)"
wrote:
Eran,
>> - 6.3. Spoofing by Counterfeit Servers
>
Eran,
>> - 6.3. Spoofing by Counterfeit Servers
>> The protocol does not support server authentication but it should prevent
>> token abuse by the Counterfeit server, shouldn't it?
> It does because the token secret is never sent.
According to section 6.3 a counterfeit server may intercept clien
Blaine,
Hanes,
We plan to submit the next version of the draft on the OAuth use cases for the
IETF 80. I would like to present it at the meeting.
With thanks,
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: S
> One of the first things a client is going to do after receiving the
> expires_in is calculate the current time plus the offset.
The client does not need to do that.
The draft oauth-v2-v11 does not specify what client has to do with the
parameter expires_in. In fact, it may do nothing. If an acc
Hanes,
>...
>There is a document in the draft repository that talks about use cases,
>namely http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/
>But it had never gotten a lot of attention on the list. (I don't know
>why.)
Actually, there is a good news here: We've got 13 queries on
>* Use cases that justify a feature seem to require two parts -- an example
>>where the feature is absent and therefore a particular problem cannot be
>>solved, and an example where the feature is present and the same problem >can
>then be solved.
There are use cases that can be supported by mo
Hannes,
I plan to be in Beijing and am interested in security topic.
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Friday, October 15, 2010 8:58 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Informal Meeting @ IE
These use cases are not in the draft
https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth.
Could you write them up?
Thanks,
Zachary
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
George Fletcher
Sent: Tuesday, September 28, 2
On behalf of the co-authors I have submitted the revised version (-01) of the
draft on the OAuth use cases.
Link: https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth/ .
The draft lists the OAuth use cases. The document's objective is to identify
the use cases that will be a base for
with our developers to determine if there is sufficient
support for this work.
Zachary
-Original Message-
From: Thomas Hardjono [mailto:hardj...@mit.edu]
Sent: Thursday, September 09, 2010 11:13 AM
To: Zeltsan, Zachary (Zachary); Faynberg, Igor (Igor)
Cc: oauth
Subject: RE: [OAUTH-WG] Deleg
on
relies on the "temporary credentials" and "token credentials", which were used
in OAuth 1.0, and not on the access tokens.
Zachary
-Original Message-
From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Tuesday, September 07, 2010 4:36 PM
To: Thomas Hardjon
, 2010 10:11 PM
To: Zeltsan, Zachary (Zachary)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Doubts about the User-Agent Profile in OAuth2
Ok I think I got it. So I believe authentication would be redirecting the
end-user to the authorization server where he needs to authenticate himself.
Now, based on
> I can't really understand how steps D, E and F works. Once I get the
> access_token in the fragment, what happens then?
In step C client receives from authorization server an access token in the
fragment part of the redirection URL, which the client provided to the
authorization server in step
The client should be capable of redirecting the user agent to the authorization
server, so the client has to be an HTTP server.
The authorization server then also redirects the user agent back to the client.
I agree that the description needs clarification. Especially the text "...and
capable
o
This is a convincing use in support of the multiple assertions.
My understanding is that in the use case the two assertions provide the
different statements of the different issuers regarding the same subject (the
person seeking a parking permit). Is there a use case that requires multiple
asser
I am not aware of the use cases where the client credentials flow is used for
authenticating anything, but a client. But the flow is used for authorizing
access to the resources other than those owned by a client.
>From OAuth2.0 -05.txt:
The client credentials flow is used when the client acts o
Section 1.5:
"The client makes the following request at an arbitrary but reasonable
interval which MUST NOT exceed the minimum interval rate provided by
the authorization server (if present via the "interval" parameter)."
My understanding is that the intervals between the client's subsequent r
I do not quite understand the combination table: what are a, b, and c
parameters?
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Wednesday, July 14, 2010 8:10 AM
To: OAuth WG
Subject: [OAUTH-WG] Quick survey:
According to the RFC 2828 an access token is rather a capability than a
password. The passwords are usually associated with the matching identifiers,
but an access token of OAuth 2.0 is used as a single credential that allows
access to a protected resource.
>From RFC 2828:
$ password
; Zeltsan, Zachary (Zachary)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] In dire need of the device flow
Arnout,
Please check with Zachary (copied here), who has been compiling the
OAuth use cases. The idea has been to keep the use cases and the
protocol aligned. So, if your use case is not present
Igor,
Discovery of the address needed for obtaining the client credentials, the
end-user authorization endpoint, and the token endpoint is common for many use
cases, where a client does not have this information. I am not aware of the use
cases with the specific requirements for discovery.
Zac
At the IETF 77 the need for documenting the OAuth use cases was discussed and I
volunteered writing a draft. The draft has been published at
http://www.ietf.org/id/draft-zeltsan-use-cases-oauth-00.txt.
At today's interim meeting its presentation did not generate any controversy.
Please provide yo
This is a link to the draft on the use cases that I presented at today's
meeting.
http://www.ietf.org/id/draft-zeltsan-use-cases-oauth-00.txt
Zachary
-Original Message-
From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org]
Sent: Tuesday, May 18, 2010 2:07 AM
To: Zeltsan, Za
Blaine,
Hannes,
The interim meeting was a good idea.
Is it certain that the meeting will be held?
Those who have to fly to Mountain View would need to buy the tickets in
advance. Do you know when the meeting-related details will be available?
With thanks,
Zachary
-Original Message-
Torsten,
I really like this use case. I think it ought to be documented on its own.
(But please let me know if you disagree and thing that it is a subset of
another use case.)
I also see potential synergy with the recursive delegation case.
For my use-cases draft, I am trying to develop a co
Eran,
The progress is good indeed.
I believe that the following comment on the draft applies also to some previous
versions of OAuth specifications.
In my opinion, the description of step A of the Web Callback Flow implies that
a client
is an HTTP server:
(A) The web client initiates
>Would you care if some proxy or other intermediary changed the contents of
>>the Authorization HTTP header?
In OAuth 1.0 the oauth_ parameters can be transmitted in the HTTP Authorization
header - this is one of the options (and is the preferred one). In that case
protection of the Authoriza
My highlights of the points raised on this thread are as follows:
A Client needs to sign a request for the temporary credentials to:
* Authenticate to the server
* Provide means for ensuring that a request has not been modified
A Client needs to sign a request for the token credentials to:
* Ensu
Peter,
I think, you have captured the meeting's discussion well.
I tried to document the meeting's agreements. Below is my summary of the main
points on which, in my opinion, the participants have agreed (or, at least,
were close to an agreement).
* OAuth should develop specifications that pro
I volunteer to be a scribe.
Zachary
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Blaine Cook
> Sent: Wednesday, February 17, 2010 9:18 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Proposed agenda for third interim meeting
>
> Hi al
61 matches
Mail list logo
