2010/7/8 Michael D Adams m...@automattic.com:
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
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:
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
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 jric...@mitre.org wrote:
Would it help if the client_ stuff were dropped from the example in the
assertion flow? I'm in favor
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
B
On Thu, Jul 8, 2010 at 9:29 AM, David Recordon record...@gmail.com 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
D
On Thursday, July 8, 2010, David Recordon record...@gmail.com wrote:
B
On Thu, Jul 8, 2010 at 9:29 AM, David Recordon record...@gmail.com 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)
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 interest
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 record...@gmail.com 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
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
A
Am 08.07.2010 um 18:29 schrieb David Recordon record...@gmail.com:
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
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 jric...@mitre.org wrote:
D
On Thu, 2010-07-08 at 12:29 -0400, David Recordon wrote:
I'm honestly trying to
B.
On Fri, Jul 9, 2010 at 1:46 AM, Blaine Cook rom...@gmail.com 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 jric...@mitre.org wrote:
D
On
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
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
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 mental
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.
B/C
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
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/tenant/acs
But I'd have no problem with supporting
D.
On Thu, Jul 8, 2010 at 9:29 AM, David Recordon record...@gmail.com 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
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
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
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 yar...@microsoft.com wrote:
Here is what I think happened.
In OAuth WRAP section 5.2.3 the wrap_assertion and
B
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
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
On 7/8/10 12:32 PM, Yaron Goland yar...@microsoft.com 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
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
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
28 matches
Mail list logo
