> 1. Server Response Format
I vote for B, though I could live with C. (A would make me sad though)
We've had a healthy and reasonable debate about the trade-offs here, but I
think the main counterargument for requiring JSON support is that it's not
quite yet a "no-brainer" to have JSON support in
On May 9, 2010, at 3:06 PM, Eran Hammer-Lahav wrote:
>
> 1. Server Response Format
>
> After extensive debate, we have a large group in favor of using JSON as the
> only response format (current draft). We also have a smaller group but with
> stronger feelings on the subject that JSON adds com
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Protocol
Author(s) : E. Hammer-Lahav, et al.
Filename: dr
> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Sunday, May 09, 2010 10:29 PM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
>
>
> >>>
> >>> Right now it depends
>>>
>>> Right now it depends on the server.
>>
>> The spec should clarify that. Suggested wording:
>>
>>
>> If the client has previously registered a redirection URI with the
>> authorization
>> server, the authorization server MUST verify that the redirection URI
>> received matches the regi
No strong views on either one.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Sunday, May 09, 2010 2:07 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
>
> DE
Re-delegation is something people asked for since we started talking about
OAuth. There is also a draft I-D about it. This is explicitly out of scope for
the core spec (but not something that should stop us from having a discussion).
The main concern is how should the resource owner express thei
This would only work for the client credentials flow (because you keep the same
authorization source). For all other flows you are breaking the authorization
boundaries.
What would be useful is to allow asking for more scope. For example, when
asking for a token (the last step of each flow), al
> -Original Message-
> From: Dick Hardt [mailto:d...@sxipper.com]
> Sent: Sunday, May 09, 2010 7:11 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: a couple editorial comments on draft-ietf-oauth-v2-03
>
> Use of term "identifier" wrt. access token and refresh token
Both endpoints deal with authorization of sorts. The reason why we have two is
one is for direct client-server communication and the other one involves the
end-user (a human).
EHL
> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Sunday, May 09, 2010 5:55 PM
> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Sunday, May 09, 2010 5:52 PM
> >> BTW: Will Brian's security considerations document be updated to be
> >> in sync with the draft?
> >
> > Brian's document was written for WRAP. We need to write a full security
Response inline.
On Sun, May 9, 2010 at 5:17 PM, Dick Hardt wrote:
>
> On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav wrote:
>
> > DEADLINE: 5/13
> >
> > I would like to publish one more draft before our interim meeting in two
> weeks (5/20). Below are two open issues we have on the list. Please r
Twitter has an interesting use case that may become common: one client needs to
delegate access to another client. Similar to the 'modify' method where the
scope of the access token can be modified, the 'delegate' method allows a
client to request delegation to another client (the delegate). Her
There has been some discussion about modifying the scope of the access token
during a refresh. Perhaps we can add another "method" to what the AS MAY
support that allows modifying the scope of an access token. Type of request is
"modify" and the scope parameter is required to indicate the new sc
I prefer authorization endpoint as it talks about the functionality of what the
client gets from that endpoint. Delegation endpoint is another alternative.
User endpoint implies there must be a user present. I envision scenarios where
an identity agent deals with the authorization for the user a
> 1. Server Response Format
>
> A. Form-encoded only (original draft)
> B. JSON only (current draft)
> C. JSON as default with form-encoded and XML available with an optional
> request parameter
I vote for B
B doesn't stop specific services also offering form-encoded or XML variants --
particu
On 2010-05-09, at 3:25 PM, Eran Hammer-Lahav wrote:
>
>> 3.2.1.1. Access Token Response
>>expires_in
>> OPTIONAL. The duration in seconds of the access token
>> lifetime.
>>
>>refresh_token
>> OPTIONAL. The refresh token used to obtain new access tokens
>>
> I would like to rename the authorization endpoint to the user endpoint. Any
> objections?
Sounds ok. An Authorization server offers token endpoints and user endpoints.
Can we change "resource owner" to "user" where applicable. Hence, a user get
directed to a user endpoint.
Suggested new text
On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav wrote:
> DEADLINE: 5/13
>
> I would like to publish one more draft before our interim meeting in two
> weeks (5/20). Below are two open issues we have on the list. Please reply
> with your preference (or additional solutions) to each item. Issues wi
On Sun, May 9, 2010 at 2:06 PM, Eran Hammer-Lahav wrote:
> DEADLINE: 5/13
>
> I would like to publish one more draft before our interim meeting in two
> weeks (5/20). Below are two open issues we have on the list. Please reply
> with your preference (or additional solutions) to each item. Issues
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Sunday, May 09, 2010 3:02 PM
> To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav
> Subject: Comments on draft-ietf-oauth-v2-03.txt
>
> I have put together some comments/suggestions regarding the curr
I have put together some comments/suggestions regarding the current draft.
3.2.1. Response Format
The authorization server MUST include the HTTP "Cache-Control"
response header field with a value of "no-store" in any response
containing tokens, secrets, or other sensitive information.
Wo
The text is in -04. -02 made the refresh token available in token refresh.
EHL
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Sunday, May 09, 2010 2:57 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Refresh t
Hi Eran,
I cannot find this text in -02 or -03. Would you please refer my to the
respective page/section?
regads,
Torsten.
Am 09.05.2010 19:56, schrieb Eran Hammer-Lahav:
Draft -02 made this possible already.
I added the following text:
The authorization server MAY issue a new ref
Add some sort of wildcard support and I think this looks good.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Thursday, May 06, 2010 4:58 PM
To: OAuth WG
Subject: [OAUTH-WG] Indicating sites where a token is valid
The OAuth2 protocol does not
The idea of embedding this information into the token is wrong. This is clearly
token metadata and that information belongs alongside the token, just like
'expires_in'.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Recordon
Sent: Friday, May 07, 2010 11:06
I would like to rename the authorization endpoint to the user endpoint. Any
objections?
EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
DEADLINE: 5/13
I would like to publish one more draft before our interim meeting in two weeks
(5/20). Below are two open issues we have on the list. Please reply with your
preference (or additional solutions) to each item. Issues with consensus will
be incorporated into the next draft. Those wi
Seems like extra complexity for little gain. The only benefit is saving server
resources when a refresh token isn't going to be used by the client, but since
most clients are likely to use it, the saving isn't much.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-b
> -Original Message-
> From: Foiles, Doug [mailto:doug_foi...@intuit.com]
> Sent: Sunday, May 09, 2010 1:07 PM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: RE: [OAUTH-WG] Autonomous clients and resource owners
> (editorial)
>
> Thanks for addressing my questions Eran.
>
> For the Assert
Thanks for addressing my questions Eran.
For the Assertion Flow I would assume the lifetime of the authorization grant
would be the same with or without the refresh token support. It doesn't seem
to me like the overall lifetime of the authorization grant would change based
upon the use of the
Draft -02 made this possible already.
I added the following text:
The authorization server MAY issue a new refresh token in which case
the client MUST NOT
use the previous refresh token and replace it with the newly issued
refresh token.
EHL
> -Original Message-
> From
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Manger, James H
> Sent: Monday, May 03, 2010 6:24 AM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus
>
> A comma is a better separator here.
> Allow
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Foiles, Doug
> Sent: Sunday, May 02, 2010 8:41 AM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
> (editorial)
>
> I wanted to poke on the idea of not allow
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Monday, April 26, 2010 11:27 PM
> To: David Recordon
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] device profile comments
>
> On Thu, Apr 22, 2010 at 5:58 PM, David Re
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Protocol
Author(s) : E. Hammer-Lahav, et al.
Filename: dr
Torsten,
Thanks for your analysis.
> 1) Resource server controls token sites (context of the realm attribute)
> 2) Authorization server controls token sites (context of token)
> In my opinion, (1) improves security and eases the practicability of OAuth2
> in scenarios with multiple sites and (
David & Marius,
> Using SWT for your access tokens seems like a reasonable way to resolve this
> for servers which care.
SWT is completely the wrong solution for this issue, if I understand it
correctly.
I haven’t followed the SWT work much, but my understanding is that it aids
interop
Marius
> ...not sure if this is a problem in real life.
> The resource that the client is trying to access should not redirect
> to an untrusted resource which is not supposed to receive access tokens.
This is a massive restriction on what a web service can do.
It breaks the web if a service can
39 matches
Mail list logo
