Kris,
The OAuth endpoint should be able to match the format(s) of the API it
protects.
I had a quick look at the APIs for 24 services implementing OAuth (v1 or
drafts of v2) as listed on the OAuth wiki.
Of these 24 APIs, the response formats supported were:
* 21 XML
* 19 JSON
* 16 XML and
On Tue, May 25, 2010 at 6:03 AM, Leah Culver leah.cul...@gmail.com wrote:
So yeah, I'm against supporting ONLY JSON. I'd be fine if the spec allowed
for form-encoded, XML or whatever else might become the hot new thing. I'm
really for leaving it up to the provider. I don't think it's up to
Back in February, I have suggested mobile web app flow to the oauth_wrap group.
Now that it is wrapped into OAuth 2.0, here is my another try, this
time for OAuth 2.0 draft.
OAuth 2.0 Mobile WebApp Flow
http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/
I really wish that
This is a legitimate concern. One other possible way to prevent this issue is
for the client to interpret the response, clear state, and refresh the page.
This is the suggested way that many Connect sites handle the situation.
I don't disagree that it may be nice to allow the client to pass a
Another newbie question about OAuth2.0.
In the Client Credential Flow (Section 3.9.1 of draft-05), the Client is
supposed to issue a Client Request Access Token. One of the fields/parameters
used is the secret_type, which is defined in Section 5.3.
However, looking at Section 5.3 it seems
But that wasn't the question... it was whether the two are closely related (as
in, should be defined in the same specification) and likely to be used together.
EHL
From: Luke Shepard [mailto:lshep...@facebook.com]
Sent: Wednesday, May 26, 2010 7:29 AM
To: Allen Tom
Cc: Eran Hammer-Lahav; Dick
+1 also. A separate signatures/tokens spec would be useful.
If service providers in the future wish to use OAuth for
authenticating users within transactions with assurance higher than LOA1,
then I strongly suggest the issue of non-repudiation is addressed.
Logging/auditing/tracking is huge issue
Hi Torsten,
Looking at your example below (with the user having
to login/consent several times), it seems what is needed
is multiple short-term (narrower) tokens that is provably
derived from one single (parent) longer-life token.
So the human user would need to consent only once
to the parent
Apologies if I'm speaking out of school :) but it seems
the Refresh Token offers an opportunity for
solving Torsten's problem.
- Instead of calling it a Refresh Token, why not
redefine it as a Service Token (or Sub-Access Token)
with a specific scope and intended Resource Server.
- In 3.3.1.,
Repeating what I said before:
- separate spec is fine by me
- part of the point I'm trying to make is that that spec shouldn't be about
signed _tokens_, but instead about signed _HTTP requests_ (so instead of
merely proving that you know a secret that came with the token, you prove
who you are
Hi Nat,
The main use case for this flow would be for mobile apps that cannot
handle long URLs, is that correct? If so, I assume that the only
problematic long URL is the initial request sent through the
user-agent to the authorization server, right?
Does the Web Client run on the phone as well,
How about we figure out the technical details of signatures before figuring
out where they're placed? :) /bikeshed
On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz balf...@google.com wrote:
Ok - to those advocating a separate spec: What if the separate spec was
really simple (a couple of
Hi Eran,
in my perception, there is some support on the list for having a request
to revoke refresh tokens. Will you add such a request to the
specification? Do you need a text proposal?
regards,
Torsten.
IMHO this would look more like a hack than proper protocol design. We need
a
I do realize several people on this list should see the parallel :) Several
folks at the last IETF OAuth meeting also brought-up the similarities.
One of the aspect unclear to me with OAuth draft-05 is the cryptographic
relationship between the Refresh Token (8xLOxBtZp8) and the Calendar
+1 on the support.
Torsten, I just wonder if you see this as (possible a part of ) a
single-sign off method?
Igor
Torsten Lodderstedt wrote:
Hi Eran,
in my perception, there is some support on the list for having a
request to revoke refresh tokens. Will you add such a request to the
Are you referring to my OpenID v.Next NewSocialService scenario?
What issues do you see doing this in v.Next rather than OAuth?
Using OpenID allows the client/RP to only discover the user's OP, which
knows where the user's calendar / address book is.
Having the OP as an intermediary allows it
But I thought that on the mobile side, TLS must be supported, and there
are tons of 3GPP and ITU-T standards that require that.
I would like to understand better was is in the way of achieving that.
(Luke, I am not challenging your argument, by the way; I just want to
understand what prevents
On Wed, May 26, 2010 at 2:17 PM, Luke Shepard lshep...@facebook.com wrote:
- Mobile handsets and networks that don't support SSL very well
We were initially worried about this when we moved GMail to
https-only. Mobile app developers were concerned about latency and
battery life. Neither proved
Since there was no response to this mail may I assume it went to /dev/null?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Yaron
Goland
Sent: Thursday, May 20, 2010 12:20 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Questions about sections 3.2/3.3
I was reading through
Hi all, I am fairly new to this mailing list so my apologies if this has
already been discussed.
Section 3.2
(http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.2)
The way in which the authorization server authenticates the end user
(e.g. username and password login, OpenID,
Nick,
You are talking about cross-site request forgery (CSRF) attacks.
These need to be mentioned in the (currently empty) Security Considerations
section. There is text about CSRF in the OAuth 1.0 Security Considerations.
There are better solutions than CAPTCHAs or always re-authenticating.
--
Hi Thomas,
I don¹t understand why there would be an issue regarding logging and
auditing if there¹s no Request Token, as in Oauth 1.0.
An OAuth2 Auth Server can audit that the user approved the request when the
user approves the request after the client redirects the browser to the
End-User
Nat,
This looks like a decent idea: allow one user-uri parameter to reference a
larger set of user-uri parameters held elsewhere -- to avoid URI size limits.
Hopefully it can be specified as another user-uri parameter -- not as a
separate flow. It could be helpful for any of the delegation
Isn't the capability that distinguishes this flow the fact that URLs can not
be more than ~500 bytes?
On Wed, May 26, 2010 at 10:13 PM, Manger, James H
james.h.man...@team.telstra.com wrote:
David,
This feels exactly like the sort of thing that should be a new flow.
Why is the size of
I'd honestly write it as a standalone few page document. We really need to
show that flows can be defined outside of the core spec from an
extensibility standpoint.
On Wed, May 26, 2010 at 10:29 PM, Nat Sakimura sakim...@gmail.com wrote:
I can do the XML2RFC thing as well.
Shall I just make
On May 26, 2010, at 4:01 PM, Brian Eaton wrote:
On Wed, May 26, 2010 at 2:17 PM, Luke Shepard lshep...@facebook.com wrote:
- Mobile handsets and networks that don't support SSL very well
We were initially worried about this when we moved GMail to
https-only. Mobile app developers were
26 matches
Mail list logo
