Re: [OAUTH-WG] Freedom of assembly for response_type

2011-02-18 Thread Breno
Example 1: OpenIDConnect End User Authorization Request for '&response_type=token+cookie' OpenIDConnect End User Authorization Response '&access_token=foo&cookie=bar' Example 2: OpenIDConnect End User Authorization Request for '&response_type=code+cookie' OpenIDConnect End User Authorization Re

Re: [OAUTH-WG] Freedom of assembly for response_type

2011-02-18 Thread Breno
On Fri, Feb 18, 2011 at 7:17 AM, Paul Madsen wrote: > Breno, why are you using 'cookie' in this context? > > SAML's 'session management' (I assume you are referring to SLO?) > functionality does not rely on browser cookies, but rather on the > participants sending a LogoutRequest carrying an id

Re: [OAUTH-WG] Client Assertion Credentials (again)

2011-02-18 Thread Eran Hammer-Lahav
By #3 Hannes meant defining another option in the spec, not just allowing it to be defined elsewhere. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Phillip Hunt > Sent: Friday, February 18, 2011 10:22 AM > To: Hannes Tschofenig > C

Re: [OAUTH-WG] Client Assertion Credentials (again)

2011-02-18 Thread Eran Hammer-Lahav
I support this approach. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Friday, February 18, 2011 10:17 AM > To: OAuth WG > Subject: [OAUTH-WG] Client Assertion Credentials (again) > > Hi all, > > I asked

Re: [OAUTH-WG] Client Assertion Credentials (again)

2011-02-18 Thread Phillip Hunt
You can put in client_assertion but also leave the 'other' credential option there as well Phil Sent from my phone. On 2011-02-18, at 10:17, Hannes Tschofenig wrote: > Hi all, > > I asked for feedback regarding the removal of the client assertion > credentials earlier this month, see >

[OAUTH-WG] Client Assertion Credentials (again)

2011-02-18 Thread Hannes Tschofenig
Hi all, I asked for feedback regarding the removal of the client assertion credentials earlier this month, see http://www.ietf.org/mail-archive/web/oauth/current/msg05261.html Unfortunately, the feedback did not lead to any new insight other than there are three groups of people: 1) Those wh

Re: [OAUTH-WG] Draft -12 feedback deadline

2011-02-18 Thread Marius Scurtescu
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

Re: [OAUTH-WG] Freedom of assembly for response_type

2011-02-18 Thread Paul Madsen
Breno, why are you using 'cookie' in this context? SAML's 'session management' (I assume you are referring to SLO?) functionality does not rely on browser cookies, but rather on the participants sending a LogoutRequest carrying an identifier for the Subject in question (and possibly a session

[OAUTH-WG] Oauth Security Draft?

2011-02-18 Thread Tschofenig, Hannes (NSN - FI/Espoo)
Hi Thorsten, Hi all, I am wondering what the status of the security draft is. The group is eagerly waiting for it. I fear that when it comes out it will be far too late and it will contain a lot of material the authors may feel comfortable but the rest of the group not necessarily. Instead of

Re: [OAUTH-WG] Draft -12 feedback deadline

2011-02-18 Thread Mark Mcgloin
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? IMO, the refresh token just provides a server side mechanism for revoking access, where resource servers are distributed, through having short lived access tokens Of cou