If the phone is compromised, original app replaced by malicious app, then
RFC8252 will not help. The assumption is that the phone is not compromised.
On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA
wrote:
> Hi,
>
> I've read rfc8252 and have questions about native apps, that I couldn't
> find a
+1 for the proposed change
Providing context around the change and to clarify that this is not a
reaction to some emergency would be useful IMO.
On Mon, Dec 3, 2018 at 1:50 PM Dick Hardt wrote:
> I disagree.
>
> Existing deployments that have not mitigated against the concerns with
> implicit s
h complex clients. I think this is another point missed in
> your reading of the text.
>
> Hope this clarifies it.
>
> EH
>
>> -Original Message-
>> From: Breno de Medeiros [mailto:br...@google.com]
>> Sent: Wednesday, March 14, 2012 10:16 AM
>>
Hi,
Nat Sakimura started a thread on the OpenID Connect list about a
breaking change introduced by rev 2.3
The paragraph in question is in section 2.1:
"A client application consisting of multiple components, each with its
own client type (e.g. a distributed client with both a confidential
serve
+1
Yes, forward compatibility and extensions will be broken if
unrecognized params are not allowed.
Marius
On Thu, Feb 16, 2012 at 10:32 AM, William Mills wrote:
> No, this is required for forward compatibility. Implementations that send
> extended parameters like capability advertisements (
+1, what John said.
Marius
On Sat, Dec 3, 2011 at 9:39 PM, John Bradley wrote:
> I remain unconvinced that at this point MTI is going to be useful.
>
> I appreciate that some people want MAC, I could not support it being MTI.
>
> The below text with Bearer as MTI the only would be acceptable,
the form scheme://host/path or
> some such.
Which is not necessarily a bad thing. It allows systems to scale and
interoperate.
> It's an opportunity to bloat scopes far out of proportion to
> what is actually needed.
>
> ____
> From: Marius S
profile", and
> "openid".
All those simple words are URIs. They are relative URIs (just the
path), but URIs nonetheless.
Marius
>
> -- Mike
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Marius
On Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke wrote:
> On 2011-10-18 17:38, Eran Hammer-Lahav wrote:
>>
>> Space is allowed inside a quoted string and is already not allowed inside
>> each scope string.
>>
>> EHL
>> ...
>
> a) yes.
>
> b) well:
>
> The value of the scope parameter is
On Wed, Oct 12, 2011 at 5:38 PM, Manger, James H
wrote:
>> One possible syntax is:
>>
>> Bearer access_token=xyz_-123,more_info=pdq
>>
>> Ultimately though, the format of the bearer token is outside of the scope of
>> the spec, and up to the participants to determine, including whether to use
>>
On Tue, Oct 4, 2011 at 12:18 PM, Julian Reschke wrote:
> On 2011-10-04 20:38, Marius Scurtescu wrote:
>>
>> On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones > <mailto:michael.jo...@microsoft.com>> wrote:
>>
>> Existing practice is that simple ASCII string
k they are parsed as a URI with no
scheme and authority only a path.
Marius
>
>
> ** **
>
> -- Mike
>
> ** **
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Mariu
I just realized that scopes are defined as a space separated list of
strings, for some reason I though they are a list of URIs.
Mark Lentczner just clarified for me that URIs are supposed to be ASCII
only. IRIs can have non-ASCII characters and can be canonically converted to
URIs using percent en
On Wed, Sep 28, 2011 at 6:40 AM, Barry Leiba wrote:
> I'd like to see more participation in this thread, besides just from
> Mike and James. What do others think?
>
I think James made it pretty clear that we have a problem and that we have
to solve it.
One solution would be for the core spec to
On Fri, Sep 23, 2011 at 7:00 AM, Mike Jones wrote:
> James Manger and others pointed out that the current credentials syntax does
> not comply with RFC 2617, nor does it match the updated credentials syntax
> contained in HTTPbis, part 7: Authentication. The current syntax in the
> bearer token d
+1
On Fri, Sep 16, 2011 at 1:06 PM, Chuck Mortimore
wrote:
> If it's not already implicit by our implementation, I'm voicing our support
> for this becoming a working group item.
>
> - cmort
>
> On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt" <
> tors...@lodderstedt.net> wrote:
>
> Hi all,
>
On Tue, Aug 2, 2011 at 3:19 PM, Aiden Bell wrote:
> Hi,
>
> I am currently implementing the device profile described at
> http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00
>
> Wanted to check this hadn't been superseded by any other document or
> protocol
> though I did notice the Googl
I think you are describing the device profile:
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00
Is that correct?
Marius
On Tue, Jul 26, 2011 at 12:18 PM, Andrew Arnott wrote:
> Trying a different DL...
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll de
On Tue, Jul 12, 2011 at 1:35 PM, Eran Hammer-Lahav wrote:
> I will withdraw my objections to the change (parsing the response_type
> string) if enough support is present. If you care about it, please speak out
> now.
The complexity of composite response types is affecting mostly
authorization s
If I read section 8.4 correctly it seems that new response types can
be defined but composite values must be registered explicitly.
I don't think this approach scales too well. OpenID Connect for
example is adding a new response type: id_token.
id_token can be combined with either code or token a
On Thu, Jun 30, 2011 at 12:45 PM, Doug Tangren wrote:
> What is the current recommended practice of storing an implicit client's
> access_tokens? LocalStorage, im mem and re-request auth on every browser
> refresh?
Both sound reasonable. I think most important is how NOT to store it,
in a cookie.
On Mon, Jun 27, 2011 at 2:22 PM, Torsten Lodderstedt
wrote:
> Hi all,
>
> while working on a new revision of the OAuth security document, a question
> arose I would like to clarify on the list.
>
> The "state" parameter is supposed to be used to link a certain authorization
> request and response.
On Fri, Jun 24, 2011 at 11:11 AM, Justin Richer wrote:
> To Eran: I really don't get your comment. Libraries are a very Good
> Thing and their use and development should be greatly encouraged by the
> OAuth community. The less that I have to write the Same Code As Last
> Time the better.
+1
If y
On Wed, Jun 15, 2011 at 7:36 PM, Manger, James H
wrote:
> It seems like an authorization server receiving a request with an
> unregistered redirect_uri of https://example.org/ can tell the user:
>
>
>
> “Permission will be passed to your browser then onto *example.org*”
>
>
>
> An authorization
On Wed, Jun 15, 2011 at 6:09 PM, Eran Hammer-Lahav wrote:
>
>> -Original Message-
>> From: Shane B Weeden [mailto:swee...@au1.ibm.com]
>> Sent: Wednesday, June 15, 2011 3:19 PM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
>>
>> > Fr
On Fri, Jun 17, 2011 at 12:13 PM, David Recordon wrote:
> +1 Eran
>
> On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav
> wrote:
>> OAuth has been successful because of its simple architecture and because it
>> is based on actual deployment experience. Offering multi-token responses
>> would
On Fri, Jun 10, 2011 at 9:34 AM, John Kemp wrote:
> George,
>
> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
>
>> I definitely don't want to change the Authorization header naming scheme. I
>> believe it should stay 'Bearer' because that's what the token is. We could
>> make it...
>>
>> A
On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones wrote:
> If you can drive a consensus decision for the name "access_token", I'd be
> glad to change the name in the spec. I agree that the current names are
> confusing for developers.
At Google we are getting the same feedback, that it is confusing f
On Thu, Jun 2, 2011 at 11:05 PM, Shane B Weeden wrote:
> Would anyone care to explain what the value of a refresh token is for peer
> to peer applications utilizing the client_credentials grant type, or
> validate if my explanation is the intended use case?
Are you asking why would an authorizat
On Wed, Jun 1, 2011 at 7:54 PM, Matias Woloski wrote:
> I've read the latest spec and some of the discussions around the user-agent
> flow and native apps. I've read about the different options to get the authz
> code (copy-paste, polling the title of the window, custom scheme, etc).
> I might be
25/11 1:15 PM, Mike Jones wrote:
>
> What you quoted below was the acceptable syntax. The Authorization Server
> and the Resource Server still need to agree upon the semantics of the bearer
> token exchanged.
>
> -- Mike
>
> -Original Message-
> From:
de ones like the ones you are asking for, such as:
>
> param="value"
>
>
>
> -- Mike
>
>
>
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
On Mon, May 23, 2011 at 1:44 PM, Skylar Woodward wrote:
> Just for the record, I spoke with Marius just now and they'll be using Eran's
> suggested URN for this (as well as 'oob' as a non-complient alias):
>
> urn:ietf:wg:oauth:2.0:oob
>
> Still remains to be codified in some way as an off
On Mon, May 23, 2011 at 10:49 AM, Doug Tangren wrote:
> Thanks It would be nice to have
> in http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-6
Section 6 is about using a refresh token to get a new access token.
Expired access tokens don't make sense in this case.
Using access tokens to
On Mon, May 23, 2011 at 10:29 AM, Doug Tangren wrote:
> Im on skype, and the audio is kind of choppy. with regard to the status
> codes as error values, which is the proper error code to use when an access
> token expires. Can someone bring that question up?
The error code would be "invalid_token
On Wed, May 11, 2011 at 11:44 AM, Lodderstedt, Torsten
wrote:
> How shall the authorization server ensure that the calling client is a
> user-agent based app (i.e. a native app could impersonate an user-agent based
> app)?
Through registration and redirect URI validation. A native app does
not
On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten
wrote:
> Hi Marius,
>
> wrt "auto-approval": how is the authorization server supposed to validated
> the client's identity in a reliable way? Otherwise another application (using
> the id of the legitimate client) could abuse the authorizatio
On Tue, May 10, 2011 at 6:25 AM, Doug Tangren wrote:
> Hi,
>
> I'm implementing an authorization and resource server at worked based on the
> oauth2 draft 15. A question arose about the user experience of users of an
> implicit client flow. I've set a one hour expiry on access tokens but now
> th
I am working through version 04 of the Bearer Token draft:
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04
Not sure how to interpret the authorization header grammar described
in section 2.1. The intent seems to be for something like:
Bearer dfgh76dfghdfg
After the scheme name, "Bearer",
On Thu, Apr 21, 2011 at 9:26 AM, Doug Tangren wrote:
> According to http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.2.2
> it doesn't look like clients of the implicit oauth2 flow should receive a
> refreshing token although it looks like the access token can optionally have
> an expire
On Tue, Apr 12, 2011 at 7:27 AM, Andrew Arnott wrote:
> I brought this concern up about a year ago. Now reviewing the latest
> drafts, I still have a concern with it. It is regarding the use of
> client_id without a password. I agree with section 3, as included below:
> Section 3. Client Authen
On Tue, Apr 5, 2011 at 3:51 PM, Eran Hammer-Lahav wrote:
> The following is my new proposal, based on Mike Jones’ and my earlier
> proposals. It is basically a combination of the two.
Looks good.
> This proposal does not allow defining new error codes unless another
> extension is involved (new
On Mon, Apr 4, 2011 at 4:14 PM, Skylar Woodward wrote:
> In our implementation (not yet public) we accept the empty string ("") as the
> value for clients not issued secrets. While this was done to simplify the
> interface and implementation, it would make it compliant in my view. In this
> ca
On Mon, Apr 4, 2011 at 12:38 PM, Zeltsan, Zachary (Zachary)
wrote:
> 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 MUS
On Mon, Apr 4, 2011 at 12:09 PM, Kris Selden wrote:
> I completely agree with you regarding not being able to authenticate a native
> client.
>
> The problem with web flow is the user experience is bad for a native app.
> Why does this matter? Because of competition – if competitors use a user
On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden wrote:
> A typical iPhone app cannot be shipped with a client secret and rightly or
> wrongly users expect to only have to enter their credentials once.
>
> What is the best profile to use for an app that can't have a client secret
> and needs a refre
What Mike said.
Definitely keep section 3 and I would really like to see the client
assertion section restored. Glad to hear there is some progress on
that front.
Marius
On Fri, Apr 1, 2011 at 6:19 AM, Mike Jones wrote:
> Also -1 on dropping section 3. Rather, we need to restore the client
gt; -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Thursday, March 31, 2011 6:07 PM
>
>> Many error codes (if not most) are not parameter specific.
>
> Like what? After a long debate, not a single use case was presented for a new
Hi Greg,
Google is working on a pure JavaScript flow which does not involve redirects.
Marius
On Thu, Mar 17, 2011 at 12:20 PM, Greg Brockman wrote:
> Hi,
>
> I notice that the current OAuth2 draft seems to have browser redirects
> baked in rather deeply. Are there any plans to add support f
On Tue, Mar 29, 2011 at 4:01 PM, Eran Hammer-Lahav wrote:
> *** Requirements
>
> The following proposal is based on two requirements:
>
> 1. Provide a way to return an OAuth error response for error situations other
> then 400 and 401. For example, if the server is temporarily unavailable, it
>
On Thu, Mar 31, 2011 at 4:56 PM, Phil Hunt wrote:
> Done.
>
> It isn't quite what the flow shows in the earlier diagram. I was originally
> avoiding client type and trying to focus on section 4 options.
>
> But this should be a better diagram.
>
> http://independentidentity.blogspot.com/2011/03/o
On Wed, Mar 23, 2011 at 12:56 PM, Torsten Lodderstedt
wrote:
> Hi Phil,
>
> looks even better now :-)
>
> As already pointed out
> (http://www.ietf.org/mail-archive/web/oauth/current/msg05599.html), "Have
> client credentials? No" does not automatically imply usage of implicit
> grant. The client
On Tue, Mar 15, 2011 at 12:43 PM, Torsten Lodderstedt
wrote:
> Congratulation!
>
> I've got some questions:
> - do you support the token_type parameter for the revocation endpoint?
No, we don't. At this point I think our implementations is compliant
with your latest draft, I will double check tha
The announcement:
http://googlecode.blogspot.com/2011/03/making-auth-easier-oauth-20-for-google.html
The documentation page:
http://code.google.com/apis/accounts/docs/OAuth2.html
Other than the core spec it implements:
- revocation endpoint
- native app support using oob and localhost (I still ha
On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg
wrote:
> +1
>
> Igor
>
> Torsten Lodderstedt wrote:
>>
>> ...
>>
>> I'm in favour to add the refresh token parameter to the implicit grant
>> flow as it would make it more useable for native apps.
I think it is much safer to go with refresh tokens o
On Sat, Feb 26, 2011 at 5:16 AM, Torsten Lodderstedt
wrote:
> thank you for your feedback.
>
> Am 03.02.2011 02:01, schrieb Marius Scurtescu:
>>
>> Following up on the Token Revocation extension proposed at:
>> http://datatracker.ietf.org/doc/draft-lodderstedt-o
On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloin wrote:
> Marius
>
> Isn't the risk of the refresh token leaking the same as the risk of the
> access token leaking, i.e. why not provide both?
Sure, but refresh tokens never die.
> IMO, the refresh token
> just provides a server side mechanism for r
On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav wrote:
> The reason why we don't return a refresh token in the implicit grant is
> exactly because there is no client authentication...
Not sure that's the main reason. AFAIK it is because the response is
sent through the user-agent and it coul
On Wed, Feb 16, 2011 at 11:06 AM, William Mills wrote:
> Token endpoint with username/password credential doesn't solve this? Depends
> on the auth scheme of course, but Bearer should provide a solution?
Not at all, in most case native apps must use the browser based 3-legged dance.
Marius
___
On Wed, Feb 16, 2011 at 10:43 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-----
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Wednesday, February 16, 2011 9:05 AM
>
>> Yes, I understand. But Native Apps have no appropriate flow n
On Wed, Feb 16, 2011 at 9:00 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-----
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Wednesday, January 26, 2011 12:09 PM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject:
On Thu, Feb 3, 2011 at 12:14 AM, Hannes Tschofenig
wrote:
> Hi all,
>
> Eran suggested to remove the Client Assertion functionality from the
> draft-ietf-oauth-v2 specification in his mail from last month:
> http://www.ietf.org/mail-archive/web/oauth/current/msg05027.html
>
> This lead to a heated
On Mon, Feb 7, 2011 at 9:59 PM, Eran Hammer-Lahav wrote:
> Mike, Brian, Dirk, and Marius – can you live with #1?
Works for me.
Marius
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav wrote:
> Hey Marius,
>
>> -Original Message-----
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Thursday, February 03, 2011 10:36 AM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Sub
On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav wrote:
> 2. Single OAuth2 scheme with sub-schemes
>
> Define a single authentication scheme for all token types with some
> attribute used to detect which scheme is actually being used.
>
> Benefits:
>
> - single scheme, reuse of the 1.0 pattern.
In case of success, why is the server supposed to return 204 instead
of 200? Just worried that this will confuse clients.
Thanks,
Marius
On Thu, Jan 13, 2011 at 8:39 AM, Marius Scurtescu wrote:
> On Wed, Jan 12, 2011 at 4:31 PM, Torsten Lodderstedt
> wrote:
>> Am 12.01.2011
On Thu, Jan 27, 2011 at 6:23 PM, Eran Hammer-Lahav wrote:
> As for the open issues: the bearer token scheme name - if it wasn’t clear, I
> plan to use every mean available to me to block the bearer token draft from
> using the ‘OAuth2’ scheme name, and will raise this issue in the WGLC, Area
> Dir
I would like to bring up one more argument to keep the assertion,
client_assertion_type and client_assertion parameters in core.
If I understood correctly, the main argument to remove them from core
was that they are underspecified and extensions are needed anyhow
before they are useful.
First of
On Fri, Jan 28, 2011 at 10:25 AM, Eran Hammer-Lahav wrote:
> -12 3.1.1:
>
> The redirection URI MUST be an absolute URI and MAY include a query
> component, which MUST be retained by the authorization server when
> adding additional query parameters.
>
> 'oob' is not an absolute URI.
Good p
On Fri, Jan 28, 2011 at 8:21 AM, Eran Hammer-Lahav wrote:
> Why not:
>
> urn:ietf:wg:oauth:2.0:oob
>
> Can you can add more flavors for different ways of floating the token/code up
> to the application. This requires no changes at all to -12 to allow this
> special case.
Using the simpler "oob"
On Thu, Jan 27, 2011 at 3:00 AM, Skylar Woodward wrote:
> Marius,
>
> I support the extension (as per my previous letter, as I missed this thread
> over the holidays) and Kiva is/was planning to support this as well. Given
> the unpredictable technology environments of many of our customers, th
On Wed, Jan 26, 2011 at 2:29 PM, Eran Hammer-Lahav wrote:
> How about turn the MUST to a SHOULD for using the x_ prefix?
OK, let's go with that.
Thanks,
Marius
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On Tue, Jan 25, 2011 at 11:08 PM, Eran Hammer-Lahav wrote:
> Thanks Marius.
>
>> -Original Message-----
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Tuesday, January 25, 2011 5:02 PM
>> To: Eran Hammer-Lahav
>> Cc: oauth@iet
On Wed, Jan 26, 2011 at 9:48 AM, Eran Hammer-Lahav wrote:
> This is not aimed at anyone in particular.
>
> Replying +1 is not justification for a major breaking change. This was raised
> in the past and consensus was that this is not a major concern. Over the past
> 10 months not a single actual
On Tue, Jan 25, 2011 at 9:59 PM, Eran Hammer-Lahav wrote:
> Simply because authentication is not what OAuth is about.
>
> OAuth is an authorization protocol for issuing access tokens. Access tokens
> can have different properties and therefore need different schemes. I was the
> first to suggest
On Tue, Jan 25, 2011 at 6:34 PM, William Mills wrote:
> As I remember there was serious objection by a few to putting versioning in
> the scheme name. OAuth, OAuth2, and soon we're on OAuthN+1 seemed to be the
> objection. Some are passionate about it and no one was sufficiently
> passionate
- 4.1. Authorization Code. It is stated that authorization code is
suitable for clients that can hold a secret. Not necessarily true, it
is the best flow for native apps, for example.
- 4.1.2 Authorization Response. Minor typo in last sentence on page
16: "size of any value is issues" => "size of
On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones
wrote:
> I’d like a sense from the working group whether others want this change, and
> if so, what the name should be changed to.
Probably this was debated, but I will ask again.
Why can't we use "OAuth2" as the scheme in all cases and require a
toke
On Thu, Jan 20, 2011 at 9:41 PM, Eran Hammer-Lahav wrote:
> Forgot to mention that I don't have any outstanding comments in my queue so
> if your feedback was not incorporated into -12, and you feel strongly about
> it, bring it up again.
>From an older email, adapted to v12:
1. The token_typ
On Thu, Jan 20, 2011 at 2:25 PM, Brian Campbell
wrote:
> Okay, sorry, I see the distinction you were making. The client could
> potentially be told the client_assertion_type and given the assertion
> (assuming it's properly encoded for all the hops) by some IdP/STS and make
> use of the use of th
On Thu, Jan 20, 2011 at 2:14 PM, Phillip Hunt wrote:
> The client does need to know how to authenticate. But given that it already
> has to know a lot about the service, you would think acceptable
> authentication types are well known to the client.
Yes, true.
> What is the problem with the c
On Thu, Jan 20, 2011 at 1:25 PM, Brian Campbell
wrote:
> I'd argue that, for reliable interoperability, both of those cases would
> require an extension or at least some level of agreement about the format
> and validation rules of the assertion.
I do agree that an extension would be useful for t
On Tue, Jan 18, 2011 at 10:12 AM, Eran Hammer-Lahav wrote:
> Client assertion credentials:
>
> The mechanism is under specified, especially in its handling of the
> client_id identifier (when used to obtain end-user authorization).
> It does not contain any implementation details to accomplish any
On Wed, Jan 19, 2011 at 9:50 AM, William Mills wrote:
> Yes it’s old, 1 week form expiring too. The specs seem to be stabilizing
> now so it’s worth updating. Has there been any other discovery proposal
> yet?
Nothing concrete AFAIK, but for SASL we also discussed using host-meta
style discove
+1
I think basic auth for client credentials belongs to an extension,
that simplifies the core spec. Is there a good reason to keep an
optional feature in core?
Marius
On Tue, Jan 18, 2011 at 3:21 PM, Igor Faynberg
wrote:
> +1
>
> Igor
>
> Anthony Nadalin wrote:
>>
>> If it is left as optiona
On Mon, Jan 17, 2011 at 7:55 AM, Richer, Justin P. wrote:
> I absolutely don't want to drop credentials being passed as parameters. I
> think that's more widely deployed than using the BASIC style auth as well.
+1
I think it is way too late for drastic changes like this. As shown by
existing im
On Sat, Jan 15, 2011 at 11:41 PM, Eran Hammer-Lahav wrote:
> Why is the token returned in the fragment using form-encoding? This makes no
> sense. It should be a JSON string for the following reasons:
>
>
>
> 1. All token responses should be the same, which will enable returning
> structured
tokens are mentioned here, and I think both refresh
and access tokens should be mentioned.
Second, it is the refresh token that should have same expiration as
the OAuth 1 token, and not the access token.
Marius
On Wed, Dec 29, 2010 at 5:40 PM, Marius Scurtescu wrote:
> Hi David,
>
>
On Wed, Jan 12, 2011 at 4:31 PM, Torsten Lodderstedt
wrote:
> Am 12.01.2011 22:19, schrieb Richer, Justin P.:
>>
>> Yes, let the server do the work. In practice, it's going to be looking up
>> the token based on the token value anyway (for bearer tokens, at least). All
>> the client really cares a
+1 for option 2 as well
Not convinced that naming the main flows Authenticated and
Unauthenticated makes sense, I think it will only increase confusion.
For example, native apps are not authenticated and they would be using
the "Authenticated" flow. I think we should stick with something along
the
On Wed, Jan 5, 2011 at 2:55 PM, Francisco Corella wrote:
>
> > Native application clients can be implemented in different
> > ways based on their requirements and desired end-user
> > experience. Native application clients can:
> >
> > o Utilize the end-user authorization endpoint as described in
On Tue, Jan 4, 2011 at 2:23 PM, Torsten Lodderstedt
wrote:
> +1
>
> I have asked myself all the time why "oob" disappeared in OAuth 2.0? Does
> Google use this feature?
Yes, we are planning to support this, exactly as described in the extension.
Marius
___
On Tue, Jan 4, 2011 at 1:27 PM, Francisco Corella wrote:
>
> We need a protocol that does both authentication and
> authorization. We can take OAuth and adapt it for
> authentication, or take OpenID and adapt it for
> authorization, or combine OpenID and OAuth (great solution
> for people who lov
I would like to propose an OAuth 2 extension that helps native clients
close the loop after the approval page. The extension defines a
special value for the redirect URI for the case when the client does
not have such a URI and it also defines that the authorization server
should provide a default
Hi David,
A few suggestions for this extension. I am assuming that you will
update it soon to conform to draft 11 of the core protocol.
1. Instead of passing an assertion why not treat it as another grant
type and pass all parameters as POST parameters. For example:
POST /token HTTP/1.1
Host: s
On Thu, Dec 23, 2010 at 9:38 PM, Francisco Corella wrote:
> Thank you very much for your detailed reading of the paper
> and your very useful comments. I've revised the paper based
> on your comments and put a new version online, with an
> acknowledgment of your contribution.
I'm glad you found
Hi Francisco,
PKAuth seems similar to OAuth 2, I think it would help if you used the same
terminology:
- application => client
- social site => authorization server
- client => end user
- reference code => authorization code
The paper claims that users do not know how to interpret domain names, w
This expiration time is just a hint, client code should work perfectly
fine without it, or with a wrong one.
Trying to understand the use case here: JavaScript code receives an
access token and the associated expires_in. It passes the access token
to backend code, and this backend code is properly
On Tue, Dec 14, 2010 at 2:54 PM, Paul Walker wrote:
> It seems to me that expires_in suffers from the same machine time
> synchronization issue and additionally throws in an indeterminable time
> amount, while expires_at would only suffer from the former.
I don't see how expires_in suffers from
rrent/msg04673.html
>
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Tuesday, December 14, 2010 4:55 PM
> To: Jitesh Bhate
> Cc: OAuth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 does not require parameter name
> oauth_token= while passing
1 - 100 of 349 matches
Mail list logo
