Subject: [oauth] Interoperability and Backwards Compatibility

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Dec 2008 17:24:52 -0500

The next steps for us to take are to resolve the open issues on a
charter and propose a charter to the IESG.  In this discussion, I'm
participating as an individual: my role as a BOF chair only extended
through the meeting.  Lisa may at some point select working group
chairs or potential working group chairs, and these people will
presumably try and get consensus here even before the working group is
formed.

One of the big issues surrounded what level of compatibility we want
to have between whatever we develop and oauth 1.0.

There are a few things that may not be obvious to those outside the
IETF.  In general, the IETF would never change the contents of
something that were signed or hashed in a protocol like oauth without
changing the name of the signature mechanism or some similar name. If
there are two ways to do things and one allows implementers to
distinguish the "old behavior" from the "new behavior," then the IETF
prefers mechanisms that allow this sort of distinguishability.  We
have sometimes done something different, but it was explicitly because
some implementations did it one way and some did it another and we
wanted to maintain compatibility with someone rather than breaking
everyone.  Those cases typically are either very obvious (the spec is
wrong and everyone does it the same way; we fix the spec) or heavily
debated.  I don't think they are likely to apply to oauth.

So, what sorts of commitments to compatibility could we make?

Well, the simplest is none.  We could charter a working group without
reference to the existing spec.  Presumably someone would propose that
the existing spec be used as input to the WG, but what that would mean
would be debated in the WG itself.  I suspect this would make no one
happy; personally I do not support it.

We could write a charter that says the work of the working group will
be based on the existing oauth specification.  What that means is that
the working group inherently accepts the existing spec as a working
group document.  In order to change the document, there has to be
rough consensus in the WG.  In other words, the current spec would be
a starting point.  This has a fair amount of power: if someone
proposes making a change and there is no agreement to do so, then
things remain as they are in the current spec.

Note that this would allow Eric to propose changes to use existing
elements for HTTP authentication, or to try and pull apart how the
document and protocol features are decomposed to try and address his
concerns.  If he gained consensus in the WG, the changes would be
made.
(I'm singling Eric out because he was particularly interested in how
much compatibility we are offering.)

In addition to basing the work on the existing spec, we could add some
language to the charter indicating that compatibility is a goal.  I'm
not sure that this would have a significant effect other than allowing
someone to bring up the argument that a change is not a good idea
because it breaks compatibility.  Someone can already bring up that
claim, and it will be discussed in the WG like anything else.

We could have language similar to the DKIM or XMPP charter saying that
incompatible changes will only be made if they are necessary to meet
the technical requirements of the WG.  This has the effect of allowing
a contributor or chair to argue that some change is unnecessary.  To
make the change, the group would need to agree both on the change and
that it is required to meet the technical requirements of the group.
I'd expect the group to need to agree on which technical requirement
was impossible without the change.

My personal opinion is that basing the work of the WG on the existing
spec is sufficient.  If oauth implementers and users show up, then
they will be able to argue against changes that do not balance
compatibility against value.  If they don't show up, the work will be
useless anyway.

--Sam
_______________________________________________
oauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Hubert Le Van Gong" <[email-masked]>
Date: Tue, 16 Dec 2008 09:00:49 +0100

Hello Sam,

Nice summary of the current state of affairs.
IMHO starting from the existing spec makes sense but compatibility
with existing OAuth 1.0 implementations cannot prevent changes
to it. Adding something (taken verbatim from the XMPP charter) like
the paragraph below will leave some leeway to make (deemed)
necessary changes.

"Although not encouraged, non-backwards-compatible changes to the
basis specifications will be acceptable if the working group
determines that the changes are required to meet the group's
technical objectives and the group clearly documents the reasons for
making them."

I like the idea Philip mentioned in a previous email on the list about
having the CFRG issuing RFC on recommended crypto methods.
This could be one of the deliverables for this charter.
I would actually recommend this list includes at least one mandated
algo to ensure interoperability between implementations of the resulting
IETF spec - this is also an essential (and obvious) goal.

BTW, was there a timeline created for this effort?

Cheers,
Hubert

---

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Dec 2008 13:05:52 -0500

>>>>> "Hubert" == Hubert Le Van Gong <[email-masked]> writes:

    Hubert> Hello Sam, Nice summary of the current state of affairs.
    Hubert> IMHO starting from the existing spec makes sense but
    Hubert> compatibility with existing OAuth 1.0 implementations
    Hubert> cannot prevent changes to it. Adding something (taken
    Hubert> verbatim from the XMPP charter) like the paragraph below
    Hubert> will leave some leeway to make (deemed) necessary changes.

    Hubert> "Although not encouraged, non-backwards-compatible changes
    Hubert> to the basis specifications will be acceptable if the
    Hubert> working group determines that the changes are required to
    Hubert> meet the group's technical objectives and the group
    Hubert> clearly documents the reasons for making them."

I mentioned this as the third option.  My question to you is what
changes do you believe that the WG would have consensus to approve
that would be blocked by this paragraph?Or alternatively, how do you believe this would help?

---

From: "Hubert Le Van Gong" <[email-masked]>
Date: Wed, 17 Dec 2008 08:12:51 +0100

Indeed I was expressing support for the third option you had mentioned.
I think this paragraph highlights a usual occurrence in the standardization
process of an existing specification: the input document is very seldom
the same as the output document (i.e. this is not a rubber stamp session).
Therefore, changes that might break backward compatibility are a possibility.
In my experience it is always better to set things straight in the charter.

Cheers,
Hubert

---

From: kellan <[email-masked]>
Date: Wed, 17 Dec 2008 08:42:51 -0500

> to have between whatever we develop and oauth 1.0.

Just to be dense, why would there, or should there be compatibility changes?

OAuth represents an extraction for the current crop of best practices
in the space, a design philosophy that has been key in its meteoric
acceptance.

-kellan

---

From: "Hubert Le Van Gong" <[email-masked]>
Date: Wed, 17 Dec 2008 15:01:07 +0100

Every time you submit a document as input to a standardization process,
no matter how good it is, you face the possibility of seeing it changed.
Otherwise why bother?
Those changes may or may not introduce incompatibilities with some
existing deployments.
Examples (and those are *only* examples) might be the formal specification
of the 2-legged version or the introduction of new security requirements.

Cheers,
Hubert

---

From: Bill de hOra <[email-masked]>
Date: Wed, 17 Dec 2008 09:44:09 +0000

Is it worthwhile released a draft that contains the same text as the 
current specification? It would be eseentially a reformatting, that 
allows people to track changes more easily in future revisions. It might 
also help get this group moving ;)

Bill

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Dec 2008 16:51:15 +0000

In the case of DKIM, we made only a few technical
changes to the domainkeys spec, you can get a feel
for what happened by comparing the relevant RFCs.
Domainkeys (the starting spec) is RFC 4870, the
resulting DKIM standard is RFC 4871. (We published
those at the same time, partly to encourage folks
to move to DKIM, which might or might not be worth
doing again.)

My impression is that in this case there'd be some
crypto related changes, but I would imagine that
those could (as happened with DKIM) be done so as
to require just software updates, so that existing
OAuth configurations could still work.

However, I think the mobile use-case we presented
might be a bigger change, hence our suggestion to
document that in a separate RFC, which would have
to be mentioned in the charter of course.

I'm not sure if any of the other things people
would like to change could be handled similarly.
(BTW - can someone post that review EKR said he'd
done but couldn't post to the other list?)

Overall, I like the approach of copying from the
XMPP or DKIM charter text. I don't think we need
to specifically call out the "allowed changes"
though, since people who want to suggest changes
will do so anyway but from what I saw at the BoF
I reckon the WG is unlikely to reach rough consensus
on gratuitous changes so I don't think we need
a list in the charter.

S.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Dec 2008 11:58:24 -0500

>>>>> "kellan" == kellan  <[email-masked]> writes:

    kellan> On Thu, Dec 11, 2008 at 5:24 PM, Sam Hartman
    kellan> <[email-masked]> wrote:
    >>  One of the big issues surrounded what level of compatibility
    >> we want to have between whatever we develop and oauth 1.0.
    >> 

    kellan> Just to be dense, why would there, or should there be
    kellan> compatibility changes?
Well, let's start with why should there be changes at all.  If you
don't think there should be changes, or you don't want to give change
control to the IETF, then you don't want to form a working group
within the IETF.

Once you agree there are changes needed, you first have to answer the
question of what changes are incompatible (something I side-stepped
because it's kind of hard) before you can answer the question of
why/if there need to be incompatible changes.  It is very likely that
answering the question of what bar should incompatible changes need to
meet is easier than answering the question of what is an incompatible
change.  Some areas where I personally think there will be
incompatible changes?  The IETF almost always requires
mandatory-to-implement security mechanisms for its specifications.
Oauth currently has no mandatory-to-implement security mechanism.  So,
it's likely that whatever comes out the other end of the IETF will be
different in that respect.  Do you view that as an incompatible
change?  The argument for yes is that there exist oauth
implementations today that comply with the current spec and will not
comply with that spec.  Do you view it as a problem?  I hope not.

I gave examples of areas where I think changes would be a really good
idea in my security review.
_______________________________________________
oauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Aaron Stone <[email-masked]>
Date: Wed, 17 Dec 2008 11:33:03 -0800

CC: OAuth@googlegroups:
There's still a lot of OAuth discussion taking place on the Google
Group. If the intention was to retire that list and move it to the IETF
list, we have a buy-in problem. IMHO, a dual-list situation isn't good
because we'll have implementers on one list and standardizers on another
list. Better if we're all in the same place.

Please make sure that you're subscribed to the [email-masked] mailing
list if you're interested in what's going into OAuth 1.1!

Re: Interop:
+1 for language that says change may occur.
+1 for listing things we do know we need to work on.

-1 against listing a closed set of allowable changes.

We have some preliminary notions of what might change, but part of the
WG process is to figure out what we don't know yet. It's already clear
that there is a high bar for incompatible changes to get WG consensus.
Requiring a re-charter to address as-yet-unknown issues is too much.

Cheers,
Aaron

On Wed, 2008-12-17 at 16:51 +0000, Stephen Farrell wrote:
[snip]

---

From: "Hubert Le Van Gong" <[email-masked]>
Date: Thu, 18 Dec 2008 08:08:57 +0100

I don't think it was suggested to list allowable changes in the
charter; if so I would certainly disagree too.
>From what you wrote should I understand a charter has already been
created? If so where is it available?

Cheers,
Hubert

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Dec 2008 12:25:15 +0000

Aaron Stone wrote:
> CC: OAuth@googlegroups:
> If the intention was to retire that list and move it to the IETF
> list, we have a buy-in problem. 

Well, I'd reckon keeping both going at least until there is a WG
formed would be better.  Some IETF WGs also have associated lists
that discuss specific implementation and/or deployment issues, so
its not that unusual a situation and is ok so long as there's
sufficient overlap of the right people.

S.

---

From: John Kemp <[email-masked]>
Date: Thu, 18 Dec 2008 12:53:19 -0500

Sam Hartman wrote:

...

> idea in my security review.

Checking the archives of this list, I can't immediately see where this 
security review is posted. Is it possible to provide a link to your review?

Regards,

- johnk

---

From: kellan <[email-masked]>
Date: Thu, 18 Dec 2008 18:03:34 -0500

> security review is posted. Is it possible to provide a link to your review?

http://groups.google.com/group/oauth/browse_thread/thread/a8875811676f39dd/47b760cd0d5d46d2

See also good comments from John Panzer and Brian.

-kellan