Re: [OAUTH-WG] Messenger Connect ships today

Congrats Sarah — big news, and great progress! Chris On Mon, Jun 28, 2010 at 11:29 AM, Sarah Faulkner wrote: > Windows Live just shipped a beta of our Messenger Connect platform. The > platform uses OAuth WRAP (among other > standards

Re: [OAUTH-WG] OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09)

No benefit. This would just be the "2.0 way" of doing it. EHL > -Original Message- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Tuesday, June 29, 2010 6:13 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: OAuth 1.0 token assertion to OAuth 2.0 token

Re: [OAUTH-WG] Draft -09

The SharedCopy experiment is working great (at least for me). However, they have a bug where the sticky notes move so please always highlight the text in addition to leaving a note. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, J

Re: [OAUTH-WG] Draft -09

I didn't see consensus around it. Specifically, what should be revoked (refresh token, access token, both, etc.). If you build consensus, I'll gladly include it. Also, it is not clear to me how to add it to the current token endpoint (unless we use a DELETE method). EHL From: Torsten Lodderste

Re: [OAUTH-WG] OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09)

On Wed, Jun 30, 2010 at 8:13 AM, Eran Hammer-Lahav wrote: > No benefit. This would just be the "2.0 way" of doing it. I see, and that's a good point. >From an implementation perspective, clients and servers that support OAuth 1 can easily implement a signature based bridge endpoint. The OAuth 1

Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

Igor, Discovery of the address needed for obtaining the client credentials, the end-user authorization endpoint, and the token endpoint is common for many use cases, where a client does not have this information. I am not aware of the use cases with the specific requirements for discovery. Zac

Re: [OAUTH-WG] Client credentials type

Or just a bit of XML signatures and encryption. The byte bloat is astounding. Yaron > -Original Message- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Tuesday, June 29, 2010 11:49 PM > To: Yaron Goland > Cc: Marius Scurtescu; OAuth WG (oauth@ietf.org

Re: [OAUTH-WG] Client credentials type

Oh and don't forget fun things like including the full cert chain which after encoding also bloats to amazing heights. > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Yaron Goland > Sent: Wednesday, June 30, 2010 5:39 PM > To: Torsten Lod

Re: [OAUTH-WG] Proposal for text for section 2

James, how can you ding client assertions credentials for doing exactly what client basic credentials do? The current spec defines that client basic credentials can go into the request body and defines this behavior in section 2. I just patterned the client assertion credentials text word for w

[OAUTH-WG] sequence diagrams

I created sequence diagrams for the main profiles supported by draft 09: https://docs.google.com/leaf?id=0B_5REGY-7RjcMjYxMzE3YTAtZWY4My00YTM5LTgzMmMtY2QwZDc3ZmEwZjhi&hl=en Let me know if they make sense and how can they be improved. Marius ___ OAuth ma

Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

On Mon, Jun 28, 2010 at 6:17 PM, Eran Hammer-Lahav wrote: > There are times when the client wants the server to fail if it doesn’t > support an extension. Implementations that have such requirements also have the option of making a new protocol that shares a lot of code with OAuth. How much feat

Re: [OAUTH-WG] Proposal for text for section 2

Yaron, > how can you ding client assertions credentials for doing exactly what client > basic credentials do? I don't like client basic credentials in request bodies either. We should ditch that as well. I am sure I have dinged it in the past. It offers too little benefit for the cost of confu

Re: [OAUTH-WG] Proposal for text for section 2

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Manger, James H > Sent: Wednesday, June 30, 2010 9:18 PM > To: Yaron Goland; oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposal for text for section 2 > > Yaron, > > > how can you ding clie

[OAUTH-WG] Underscore, dash, green, blue

First, sorry about this. :) I do my best not to ask the group this kind of questions and just pick something on my own, but I can't decide so I'll run a quick vote (yes, a VOTE - I can't imagine seeking a consensus call on this). -09 uses underscores for parameter names (except for in the heade

Re: [OAUTH-WG] Underscore, dash, green, blue

On Wed, Jun 30, 2010 at 10:08 PM, Eran Hammer-Lahav wrote: > 1. Use dashes throughout > 2. Use underscores for all parameter names (headers included), dashes for > all values > 3. Use underscores throughout 3 ___ OAuth mailing list OAuth@ietf.org https:

Re: [OAUTH-WG] Underscore, dash, green, blue

3 except headers. 2010/7/1 Eran Hammer-Lahav : > First, sorry about this. J > > > > I do my best not to ask the group this kind of questions and just pick > something on my own, but I can’t decide so I’ll run a quick vote (yes, a > VOTE – I can’t imagine seeking a consensus call on this). > > > >