Hey -
I've got a bunch of nit-type comments on oauth2 draft 9. I'm going to
bundle them all together here.
There are a few more significant issues, those I'll start separate threads for.
Introduction, paragraph 2:
"In the traditional client-server authentication model,... presenting
the resour
D (No, I will not be in Maastricht)
--
James Manger
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Recordon
Sent: Friday, 9 July 2010 2:29 AM
To: OAuth WG
Subject: [OAUTH-WG] POLL: Are you going to Maastricht?
I'm honestly trying to decide myself and a few other
Nice summary, thanks Brian!
I think there is a third issue as well, i.e. what the use case for client_id
actually is.
I think Chuck's use case has client_id used to disambiguate the purpose of
the SAML assertion. We have a similar use case, both for SAML assertions
and three-legged OAuth approva
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, please make sure
that it is present in the next version of the draft. (Of course, the WG
will nee
That sounds like a very accurate description to me.
-cmort
On 7/8/10 3:27 PM, "Brian Campbell" wrote:
Maybe I'm the only one having a hard time following this thread but I
suspect I'm not alone. I'm going to try and just summarize the
issues - mostly for my own edification but hopefully this
Maybe I'm the only one having a hard time following this thread but I
suspect I'm not alone. I'm going to try and just summarize the
issues - mostly for my own edification but hopefully this may help
others too. Please let me know if I'm off base.
The thread originally started with a discussion
In regards to the discussion of versioning and namespaces I would suggest we
follow RFC 3864. If someone wants to add an extension to OAuth then they can
either write an RFC or they can use the lightweight review mechanism similar to
the one RFC 3864 introduced.
Just a thought,
On 7/8/10 12:32 PM, "Yaron Goland" wrote:
Here is what I think happened.
In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format
arguments were used to allow clients to authenticate themselves to token
endpoints in two legged OAuth scenarios.
In OAuth 2.0 two legged OAuth
I think the idea was to create a separate spec for the device flow, so
that the core spec can be finished faster.
The device flow described in version 6 can be the starting point for
this separate spec, and if you are saying that something like this is
already implemented, then it could be quite c
Hi,
Long story short, a while ago we (the company I work for) created our
own protocols, which after investigation, matched the device flow in the
earlier versions of the OAuth2 spec exactly. I'm in favor of open
standards, so I would like to conform to the OAuth2 specification, if
possible.
B
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
And I am now seriously, seriously confused about your use case.
Why do you need refresh tokens?
Can you give more details?
On Thu, Jul 8, 2010 at 12:32 PM, Yaron Goland wrote:
> Here is what I think happened.
>
> In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format
> argume
D
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Recordon
Sent: Thursday, July 08, 2010 9:29 AM
To: OAuth WG
Subject: [OAUTH-WG] POLL: Are you going to Maastricht?
I'm honestly trying to decide myself and a few other people are in similar
situations. Thus a poll
Here is what I think happened.
In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format
arguments were used to allow clients to authenticate themselves to token
endpoints in two legged OAuth scenarios.
In OAuth 2.0 two legged OAuth as a separate definition was removed and instea
D.
On Thu, Jul 8, 2010 at 9:29 AM, David Recordon wrote:
> I'm honestly trying to decide myself and a few other people are in similar
> situations. Thus a poll:
> A) Yes, I'm going to be in Maastricht
> B) Maybe, depends on the number of OAuth WG members going
> C) Maybe, depends on some other re
OK, I *think* I understand your use-case... Just to be clear, even
after your internal discussions, you don't see a need for a client
secret in this flow?
Our SAML endpoints encode the tenant in the URL like so:
https://www.google.com/accounts//acs
But I'd have no problem with supporting per te
D
On 2010-07-08, at 9:29 AM, David Recordon wrote:
> I'm honestly trying to decide myself and a few other people are in similar
> situations. Thus a poll:
> A) Yes, I'm going to be in Maastricht
> B) Maybe, depends on the number of OAuth WG members going
> C) Maybe, depends on some other reason
B/C
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
The bridge flow was meant to be used in a mixed OAuth 1 and OAuth 2
environment, it allows the consumer to obtain a token using signatures
and then access protected resources with no signatures. Now that
signatures are re-introduced in OAuth 2 I don't think there is a need
for such an approach.
Th
Leaving it loosely defined is good in my opinion.
The way I see scope is as a way to limit the power of a token. Examples
of this might be "mail" to limit to only accessing e-mail, or
"read-only" for something like a calendar sync application pulling
events out of an online calendar. My menta
To me, scope means "the stuff being accessed", but can also mean permissions,
duration, etc. I raised this issue a while back but since we could not agree on
what exactly is included in scope, it was left vague. The key is the
space-delimited values and how they relate to each other ("a b" cover
Today the definition of scope is vague. But I have seen mails on this list
(such as Lukas Rosenstock's post
http://www.ietf.org/mail-archive/web/oauth/current/msg03560.html which is just
one example) that assert that scope represents the permissions that a client is
requesting.
When we use sco
D
On Jul 8, 2010, at 9:29 AM, David Recordon wrote:
I'm honestly trying to decide myself and a few other people are in similar
situations. Thus a poll:
A) Yes, I'm going to be in Maastricht
B) Maybe, depends on the number of OAuth WG members going
C) Maybe, depends on some other reason
D) No
If
B.
On Fri, Jul 9, 2010 at 1:46 AM, Blaine Cook wrote:
> A, BUT I will be unable to attend Monday-Wednesday. I'll be around
> Thursday / Friday to work on issues and so forth if others will be
> there, too.
>
> b.
>
> On 8 July 2010 17:43, Justin Richer wrote:
>> D
>>
>> On Thu, 2010-07-08 at 12:
A, BUT I will be unable to attend Monday-Wednesday. I'll be around
Thursday / Friday to work on issues and so forth if others will be
there, too.
b.
On 8 July 2010 17:43, Justin Richer wrote:
> D
>
> On Thu, 2010-07-08 at 12:29 -0400, David Recordon wrote:
>> I'm honestly trying to decide myself
A
Am 08.07.2010 um 18:29 schrieb David Recordon :
> I'm honestly trying to decide myself and a few other people are in similar
> situations. Thus a poll:
> A) Yes, I'm going to be in Maastricht
> B) Maybe, depends on the number of OAuth WG members going
> C) Maybe, depends on some other reason
D
On Thu, 2010-07-08 at 12:29 -0400, David Recordon wrote:
> I'm honestly trying to decide myself and a few other people are in
> similar situations. Thus a poll:
> A) Yes, I'm going to be in Maastricht
> B) Maybe, depends on the number of OAuth WG members going
> C) Maybe, depends on some other r
D. No.
But I am looking forward to a long list of feedback for -10 and will do my best
to attend virtually.
EHL
On 7/8/10 9:29 AM, "David Recordon" wrote:
I'm honestly trying to decide myself and a few other people are in similar
situations. Thus a poll:
A) Yes, I'm going to be in Maastrich
> A) Yes, I'm going to be in Maastricht
> If you're missing context, in a few weeks it is the IETF meeting
> in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a
> meeting scheduled all afternoon Tuesday the 27th.
And don't forget about several other sessions that might be of inter
A)
Igor
David Recordon wrote:
I'm honestly trying to decide myself and a few other people are in
similar situations. Thus a poll:
A) Yes, I'm going to be in Maastricht
B) Maybe, depends on the number of OAuth WG members going
C) Maybe, depends on some other reason
D) No
If you're missing cont
D
On Thursday, July 8, 2010, David Recordon wrote:
> B
>
> On Thu, Jul 8, 2010 at 9:29 AM, David Recordon wrote:
>
> I'm honestly trying to decide myself and a few other people are in similar
> situations. Thus a poll:A) Yes, I'm going to be in MaastrichtB) Maybe,
> depends on the number of OA
B
On Thu, Jul 8, 2010 at 9:29 AM, David Recordon wrote:
> I'm honestly trying to decide myself and a few other people are in similar
> situations. Thus a poll:
> A) Yes, I'm going to be in Maastricht
> B) Maybe, depends on the number of OAuth WG members going
> C) Maybe, depends on some other re
I'm honestly trying to decide myself and a few other people are in similar
situations. Thus a poll:
A) Yes, I'm going to be in Maastricht
B) Maybe, depends on the number of OAuth WG members going
C) Maybe, depends on some other reason
D) No
If you're missing context, in a few weeks it is the IETF
Already is.
http://github.com/theRazorBlade/draft-ietf-oauth/raw/3e9a1e67807b7bbfe79ca4045a44b613ef45c990/draft-ietf-oauth-v2.txt
EHL
On 7/8/10 8:21 AM, "Justin Richer" wrote:
Would it help if the client_ stuff were dropped from the example in the
assertion flow? I'm in favor of it being allo
Would it help if the client_ stuff were dropped from the example in the
assertion flow? I'm in favor of it being allowed, but if the general use
case is going to be without it then the example should reflect that and
cut down on the confusion.
-- Justin
On Wed, 2010-07-07 at 18:01 -0400, Brian
On Thu, Jul 8, 2010 at 11:53 AM, Kris Selden wrote:
> The refresh token is key to separating concerns of the protected resource
> from the auth server.
>
> I think this is succinctly explained the original rationale (refresh token =
> refresh secret):
> http://wiki.oauth.net/ScalableOAuth#Append
Hi,
I took a look at the OAuth 1 Bridge Flow suggested by
Marius, the thread "OAuth 1 Bridge Flow" and had some thoughts:
I do not really see the necessity for such a flow.
First of all, all participating parties have to be modif
The refresh token is key to separating concerns of the protected resource from
the auth server.
I think this is succinctly explained the original rationale (refresh token =
refresh secret):
http://wiki.oauth.net/ScalableOAuth#Appendix
On Jul 8, 2010, at 1:51 AM, Laurens Van Houtven wrote:
> J
Just pitching in as someone writing something that might want a
refresh token but *really* doesn't understand why he'd need them. They
make very little sense to me; why not just make the token that allows
you to access a protected resource last longer? Use case: we've got
protected resources that g
The sequence diagrams look just fine, I guess they could be really
helpful for an OAuth newbie!
2010/7/1 Marius Scurtescu :
> I created sequence diagrams for the main profiles supported by draft 09:
> https://docs.google.com/leaf?id=0B_5REGY-7RjcMjYxMzE3YTAtZWY4My00YTM5LTgzMmMtY2QwZDc3ZmEwZjhi&hl=
2010/7/8 Michael D Adams :
> If an implementor needs cross domain functionality, there's a new,
> safer technology that allows both ends to whitelist who they talk to.
>
> Cross-document messaging
> http://www.w3.org/TR/html5/comms.html#crossDocumentMessages
>
> I'm not familiar with cross-document
41 matches
Mail list logo
