Subject: [OAUTH-WG] Breakfast BoF minutes

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Jul 2009 08:50:02 +0200

We just finished an OAuth breakfast Bof at IETF 75. Here are the topics
we discussed, in no particular order. Various folks at the meeting
volunteered to start separate threads about some of these.

1. OAuth for delegation. Currently the spec addresses only single-layer
delegation ("three-legged") and is silent about multi-layer delegation.
If we don't define this in a standard way, different people will find
different, non-standard ways to do it. We need to gather use cases and
work on specifying it.

2. Non-WWW use cases. Let's gather these (shared calendaring, XMPP
chatroom ownership, exchange of app-level blobs, etc.).

3. OAuth for authentication. In this case, OAuth could be used to
replace DIGEST for authn. It's possible that SCRAM could be used as a
signing method. The group also talked about defining various related
SASL mechanisms (SAML, OpenID, OAuth).

4. Channel bindings. There are similarities here to HTTPS/DIGEST (Leif
Johansson mentioned an expired I-D about this and volunteered to post to
the list).

5. Attribute extensions. Could we use OAuth for transporting existing
SAML formats?

6. Split off the header signing aspects of OAuth, or at least call that
out more clearly in the spec? Someone at the BoF likened this to "DKIM
for the Web".

7. The spec is not designed to be profiled and extended. Is this OK?

8. Do callbacks need to be forward-ported to the I-D?

9. Discussion redirects. Currently most folks still take their items to
the googlegroups list. That's fine, but going forward we would like to
use the WG list for topics related to the core specifications.

If you were at the BoF and see errors in what I've reported, please post
in reply.

Thanks!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 29 Jul 2009 03:28:05 -0400

Peter,

Excellent notes and meteoric delivery. Many thanks!

Igor

On 7/29/2009 2:50 AM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkpv8RkACgkQNL8k5A2w/vzfHACeOelyjPVk94WH5QkHmEv1oEnt
> DX8Ani+zGPn2Yx34/EpIKeInDtmQnBaj
> =tiM7
> -----END PGP SIGNATURE-----
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 29 Jul 2009 23:07:21 -0700

Thanks Peter for great and speedy notes.

It is somewhat disappointing that the majority of these items are outside the scope of the WG and seem to distract us from making progress on the core protocol... I'd like to remind everyone that we are not here to invent a new delegation protocol from scratch, and at the same time, OAuth is not a codename for 'a popular protocol I can change as I see fit for my own needs, and still call it OAuth'.

Comments inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Peter Saint-Andre
> Sent: Tuesday, July 28, 2009 11:50 PM
> 

This has been raised many times over the past 2 years and no one has actually offered real world use cases.
 
> chatroom ownership, exchange of app-level blobs, etc.).

What does non-www mean? Non-HTTP?
 
> SASL mechanisms (SAML, OpenID, OAuth).

We need to keep separate authentication of protected resources requests and authentication of end users (for granting access). OAuth authentication has nothing to do with SAML or OpenID. How the end user is authenticated is strictly out of scope for OAuth (the user is redirected, magic happens, user redirected back).

As for supplementing Digest with a new authentication methods, that is part of our charter. Also, I think Alexey has an action item to write a review of using SCRAM in OAuth... was any progress made on this front?
 
> Johansson mentioned an expired I-D about this and volunteered to post to

This is a bit outside my personal area of expertise, but it does look relevant in the discussion of a new 2617-based authentication method.
 
> 5. Attribute extensions. Could we use OAuth for transporting existing

I would ask for use cases but would rather just keep this discussion out of scope for now given the need to focus on getting chartered work done.
 
> out more clearly in the spec? Someone at the BoF likened this to "DKIM

Split off from what?
 
> 7. The spec is not designed to be profiled and extended. Is this OK?

Nor does it really prevent it as the many extensions prove. We do need to address this to make it easier and clearer. As for profiling, this is what we are trying to do to the community spec in the WG, and as we make progress, I think we will see how easy/hard it is.
 
> 8. Do callbacks need to be forward-ported to the I-D?

Huh?
 
> use the WG list for topics related to the core specifications.

Nope. The existing list is the right home for 1.0 and 1.0a support issues, including all code related topics (libraries, etc.). I have yet to see threads posted to the Google group that should have been posted to the WG list.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 30 Jul 2009 10:41:42 -0700

First, my issue with scope isn't about technical changes, but about being productive. We have made no progress so far and to start branching out at this point will make it even worse.

As for individual points, I did comment on each item...

EHL

> From: Leif Johansson [mailto:[email-masked]]
> Sent: Thursday, July 30, 2009 12:02 AM
> To: [email-masked]
> Cc: Eran Hammer-Lahav
> Subject: Re: [OAUTH-WG] Breakfast BoF minutes
> 
> On Thursday 30 July 2009 08.07.21 Eran Hammer-Lahav wrote:
> > It is somewhat disappointing that the majority of these items are
> outside
> > the scope of the WG and seem to distract us from making progress on
> the
> > core protocol... I'd like to remind everyone that we are not here to
> invent
> > a new delegation protocol from scratch, and at the same time, OAuth
> is not
> > a codename for 'a popular protocol I can change as I see fit for my
> own
> > needs, and still call it OAuth'.
> >
> 
> Could you be more specific in your criticism? Which of the suggestions
> do you
> think is out of scope and why (given our charter)? Note that change-
> control
> for the WG charter ultimately resides with the IESG.
> 
> 	Cheers Leif

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 31 Jul 2009 09:57:16 -0700

It would be nice to have *any* discussion at this point about what's in scope. Really, anything at all... Or maybe everyone is just happy with the two draft and we should sent them to last call? Not likely. I opened a couple of issues and have seen no response.

We are in agreement but I would *prefer* that we let the chartered work at least begin before we start taking attention off and on to other (related) matters.

EHL

> Sent: Friday, July 31, 2009 4:05 AM
> To: [email-masked]
> Cc: Eran Hammer-Lahav
> On Thursday 30 July 2009 19.41.42 Eran Hammer-Lahav wrote:
> > First, my issue with scope isn't about technical changes, but about
> being
> > productive. We have made no progress so far and to start branching
> out at
> > this point will make it even worse.
> 
> I agree that progress is needed on the core specifications but that
> doesn't
> preclude thinking and talking about what comes next.
> 
> If you say "Lets not add documents to our charter before we finish what
> we
> already have on our plate" then I fully agree.
> 
> I don't agree that _discussions_ on the list need to get shut down just
> because they aren't part of the charter - how could we ever decide on
> new
> charter items otherwise?
> 
> 	Cheers Leif

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 31 Jul 2009 09:59:04 -0700

> Sent: Friday, July 31, 2009 4:02 AM
> To: [email-masked]
> Cc: Eran Hammer-Lahav

> The idea was to describe header signing independent of oauth (and have
> oauth reference that specification) which uses header signing as a way
> to
> define an http authentication mechanism.

When you say 'header signing' do you mean signing an HTTP header? OAuth does not provide that today.

EHL