Re: [OAUTH-WG] Simpilfying use of assertions when requesting an access token

2010-09-02 Thread David Recordon
I like that this also collapses the grant_type=assertion and assertion_type=foo. On Thu, Sep 2, 2010 at 2:28 PM, Eran Hammer-Lahav wrote: > Yes. > > -Original Message- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Thursday, September 02, 2010 2:27 PM > To: Eran Hammer-Lahav >

Re: [OAUTH-WG] comments/questions on draft 10

2010-09-02 Thread Oleg Gryb
> > p.11 What is the meaning of "... the authentication of the client is based >on the user-agent's same-origin policy." ? As far as I know, this policy >restricts the hosts the JavaScript client is allowed to interact with. How >does >this "feature" authenticate the client on the authoriza

Re: [OAUTH-WG] more than one assertion?

2010-09-02 Thread Anthony Nadalin
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 assertion

Re: [OAUTH-WG] Doubts about the User-Agent Profile in OAuth2

2010-09-02 Thread Zeltsan, Zachary (Zachary)
In my opinion that is correct. Once you have a script for extracting an access token locally, you do not need to download it again. I do not know how that is implemented by Facebook. From: Jonathan Leibiusky [mailto:ionat...@gmail.com] Sent: Monday, August 30, 201

Re: [OAUTH-WG] Simpilfying use of assertions when requesting an access token

2010-09-02 Thread Eran Hammer-Lahav
Yes. -Original Message- From: Justin Richer [mailto:jric...@mitre.org] Sent: Thursday, September 02, 2010 2:27 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Simpilfying use of assertions when requesting an access token +1 I've never liked the notion of

Re: [OAUTH-WG] Simpilfying use of assertions when requesting an access token

2010-09-02 Thread Justin Richer
+1 I've never liked the notion of not being able to extend the "grant type" field, and this change addresses that particular gripe. Just so I'm clear here: an extension that defines its own url-defined grant type can also legally add and remove parameters from the endpoint, right? -- Justin On

[OAUTH-WG] Simpilfying use of assertions when requesting an access token

2010-09-02 Thread Eran Hammer-Lahav
I would like to make this change in -11: Instead of the current user of the 'assertion' grant type - POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=assertion& assertion_type=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion& a

Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension

2010-09-02 Thread Bill de hÓra
> Because 2.0 deployments are not likely > to share the same credentials Ok I understand, so that's "the value of which is the.." piece. I'm not clear we can say one way or another which credentials are supplied, but if that's the assumption/desire, then perhaps the ID should document it. In an

Re: [OAUTH-WG] comments/questions on draft 10

2010-09-02 Thread Eran Hammer-Lahav
-Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Tuesday, August 24, 2010 3:42 PM > p.11 What is the meaning of "... the authentication of the client is based on > the user-agent's same-origin policy." ? As far as I

Re: [OAUTH-WG] comments/questions on draft 10

2010-09-02 Thread Eran Hammer-Lahav
It's right there in the definition: If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sen

Re: [OAUTH-WG] issuing new refresh tokens

2010-09-02 Thread Torsten Lodderstedt
+1 Am 02.09.2010 19:11, schrieb Eran Hammer-Lahav: Is this reasonable? "The authorization server MAY issue a new refresh token, in which case, the client MUST discard the old refresh token and replace it with the new refresh token." This is as much consensus as I w

Re: [OAUTH-WG] POST-only on token endpoint? [was: temperature check: json input to token endpoint]

2010-09-02 Thread Eran Hammer-Lahav
Didn't see consensus on making any of these changes. Dropping from my queue. EHL -Original Message- From: Justin Richer [mailto:jric...@mitre.org] Sent: Wednesday, July 14, 2010 8:38 AM To: Eran Hammer-Lahav Cc: Brian Eaton; oauth@ietf.org Subject: Re: [OAUTH-WG] POST-only on token endpo

Re: [OAUTH-WG] issuing new refresh tokens

2010-09-02 Thread Eran Hammer-Lahav
Is this reasonable? "The authorization server MAY issue a new refresh token, in which case, the client MUST discard the old refresh token and replace it with the new refresh token." This is as much consensus as I was able to extract. EHL -Original Message- From:

Re: [OAUTH-WG] Quick survey: fragment vs. query

2010-09-02 Thread Eran Hammer-Lahav
No exactly… Consensus is on: 1. Code in query 2. Token in fragment 3. Code and Token in fragment There was some interest (but no consensus) for: 4. Code in query and Token in fragment The spec always had #1 (web server) and #2 (user agent). Draft -10 has #4 but based on feedback from Brian an

Re: [OAUTH-WG] Alternative ways to pass Authorization Request Parameters

2010-09-02 Thread Eran Hammer-Lahav
This is not needed. All you have to do in your extension is to override this. Basically, you are defining a new parameter that replaces other parameters - just say that. Any server supporting your extension will need to know how to handle it anyway. EHL -Original Message- From: oauth-b