Subject: [OAUTH-WG] Quick survey: fragment vs. query

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 14 Jul 2010 05:10:14 -0700

Please answer this based on actual use cases. When returning parameters
using the redirection URI call, which of these combinations make sense?

         | Code | Token | Code & Token
---------+------+-------+--------------
Fragment |  a   |   1   |   3
Query    |  2   |   b   |   c
Split*   | n/a  |  n/a  |   d

* token in fragment, code in query

Known use cases:

1 - current user-agent flow
2 - current web-server flow
3 - as described by Brian and Naitik

Do you need any of these?

a - 
b -
c - 
d - current -10 code-and-token proposal

EHL

---

From: Brian Eaton <[email-masked]>
Date: Wed, 14 Jul 2010 10:04:37 -0700

I can't parse this diagam, but here's my take:

- web server flow should always return just a code.
   parameter always goes in the query string
   it would be sort of reasonable to have the code exchange return
just an access token, instead of a refresh token and an access token.
Or a refresh token with a shorter lifetime than indefinite.

- user-agent flow can reasonably return either just a token, or a
token and a code
   both parameters always go in the fragment, to avoid busting the browser cache
   same comments about lifetime of refresh tokens...

Cheers,
Brian

On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: David Recordon <[email-masked]>
Date: Wed, 14 Jul 2010 11:11:11 -0700

I caught up on the thread and with Luke yesterday afternoon and am fine with
the user-agent flow using the fragment in the token and code case.

---

From: Naitik Shah <[email-masked]>
Date: Wed, 14 Jul 2010 11:48:44 -0700

2 and 3 are practically most interesting imho.

(b) is interesting in that if a client application does have SSL, then it's
the simplest flow of all.

-Naitik

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 14 Jul 2010 23:36:26 +0200

2 is a must have from my point of view.

I would also like to see support for b. In this case, additional means 
for client authentication should be considered.

regards,
Torsten.

>           | Code | Token | Code&  Token

---

From: Brian Eaton <[email-masked]>
Date: Wed, 14 Jul 2010 14:40:47 -0700

On Wed, Jul 14, 2010 at 2:36 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> I would also like to see support for b. In this case, additional means for
> client authentication should be considered.

b is token on query string?

What's the use case for that?

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 14 Jul 2010 23:48:52 +0200

> What's the use case for that?
Yepp. That's an optimization of use case 2. That way the authz server 
does not need to store the authorization transaction's results in a 
database and there is no need to perform a a second request.

regards,
Torsten.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 14 Jul 2010 14:52:12 -0700

On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> Yepp. That's an optimization of use case 2. That way the authz server does
> not need to store the authorization transaction's results in a database and
> there is no need to perform a a second request.

The authorization server doesn't need to store the transaction results
in a database regardless, the authorization code can be a signed
message.

The second request (as you pointed out in your original mail) is
currently used to verify the client identity.  Do you have a
suggestion for an alternate mechanism?

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 14 Jul 2010 23:59:02 +0200

> in a database regardless, the authorization code can be a signed

That's an indeed option. But then the whole data is transported twice 
between authz server and client.

> suggestion for an alternate mechanism?

A digital signature over the authz request? Alternatively, the authz 
server could encrypt the authz response.

regards,
Torsten.

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Wed, 14 Jul 2010 17:01:40 -0500

I do not quite understand the combination table: what are a, b, and c parameters?

Zachary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, July 14, 2010 8:10 AM
To: OAuth WG
Subject: [OAUTH-WG] Quick survey: fragment vs. query

Known use cases:

a - 
b -
c - 

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 14 Jul 2010 15:33:15 -0700

At some point this brings us back to 1.0...

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 14 Jul 2010 15:35:49 -0700

a - code in fragment
b - token in query
c - code and token in query
d - code and token split -10

EHL

---

From: Brian Eaton <[email-masked]>
Date: Wed, 14 Jul 2010 16:02:47 -0700

On Wed, Jul 14, 2010 at 2:59 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> A digital signature over the authz request? Alternatively, the authz server
> could encrypt the authz response.

Is anybody else implementing that model...?

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 15 Jul 2010 07:57:17 +0200

We implement the second option in our SSO protocol.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 15 Jul 2010 08:02:19 +0200

why that? If there will be a signature proposal for resource server 
access, the same (simplified?) model could be applied to the authz 
server's API.
And as I pointed out in my original posting, I see this as a _further_ 
option not the only one. While it is technically more complicated, it 
has its adavantages (we already discussed). One further advantage of 
already signing the inbound request is that the authz server can refuse 
unauthorized requests early.

regards,
Torsten.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 14 Jul 2010 23:25:46 -0700

On Wed, Jul 14, 2010 at 11:02 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> why that? If there will be a signature proposal for resource server access,
> the same (simplified?) model could be applied to the authz server's API.

Sure.  Other folks have used signed URLs in this kind of protocol as
well: http://developer.yahoo.com/bbauth/user.html.

Why not write up your proposal as an alternate flow (right next to
"user-agent" and "web-server") and see whether other people will
implement it?

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 18 Jul 2010 15:12:22 +0200

> "user-agent" and "web-server") and see whether other people will

I already proposed such an alternative flow 
(http://www.ietf.org/mail-archive/web/oauth/current/msg02112.html), but 
did not gain support. I probably will give it another try once the WG 
reached consensus regading a new signature mechanism.

It's not my current focus. There are more important open issue, e.g. 
scope definition, resource server identification, and token revocation. 
I just contributed my honest opinion to Eran's survey :-)

regards,
Torsten.