Subject: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 16 Feb 2009 21:52:10 +0200

Stephen ask me how their document
draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in the
charter text. 

Independent of this particular document, I believe that we should focus our
initial efforts on the Base OAUTH specification rather than working on
extensions. As such, I would say that (depending on the progress of the work
with the main specification) we should discuss extensions in the summer
timeframe. 

Regarding this specific extension: I read through
draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make sure
that I understood the extension correctly. Here is a message flow that Jeff
created some time ago. This document suggests to skip the message exchanges
marked as (2.*). This means that the redirect from the Service Provider to
the Customer and the subsequent steps of user authentication and
authorization are replaced with the ability to carry some username/password
in the Access token when the Consumer sends the request to the Service
Provider. 

                                            photos.example.net
                                              +----------+
                                              |          |
                                              | OAuth    |
                    printer.example.com       | Service  |
                        +--------+            | Provider |
                        |        |            |          |
                        | OAuth  |            |[protected|
                        |Consumer|            |resources]|
  +----+                |        |            |          |
  | UA |                |  [RP]  |            |   [SP]   |
  +-+--+                +---+----+            +----+-----+
    |                       |                      |
    | 1.0. User Agent inter-|                      |
    | acts with Consumer    |                      |
    | site [optional]       |                      |
    |<--------------------->|                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 1.1. UA informs/directs                      |
    | Consumer to do something                     |
    | with a resource (photo)                      |
    | at SP                 |                      |
    |---------------------->|                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    |                       | 1.2. Consumer attempts
    |                       | accessing photo at SP|
    |                       |--------------------->|
    |                       |                      |
    |                       |                      |
    |                       | 1.3. SP replies with |
    |                       | a HTTP 401 containing|
    |                       | a "OAuth" www-authn  |
    |                       | header field         |
    |                       |<---------------------|
    |                       |                      |
    |                       |                      |
    |                       | 1.4. Consumer replies|
    |                       | with a request for   |
    |                       | "unauthorized Request|
    |                       | Token" (uRT) via POST|
    |                       | to SP's "request token
    |                       | URL"                 |
    |                       |--------------------->|
    |                       |                      |
    |                       |                      |
    |                       | 1.5. SP issues uRT & |
    |                       | token secret to      |
    |                       | Consumer.            |
    |                       |<---------------------|
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 2.0. Consumer redirects                      |
    | UA to SP "User Author-|                      |
    | ization URL" including|                      |
    | the uRT.              |                      |
  +<- - - - - - - - - - - - |                      |
  . | (indirected via UA)   |                      |
  . |                       |                      |
  +-------------------------+--------------------->|
    |                       |                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 2.2. User authenticates with the Service     |
    | Provider (optional methods vary, realization |
    | is out of scope)                             |
    |<============================================>|
    | 2.3. User grants or declines permission      |
    | for the Service Provider allow Consumer      |
    | access to the resource (photo).              |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 2.4. If permision granted, UA redirected back|
    | to Consumer's "Callback URL", conveying the  |
    | uRT.                  |                      |
  +<- - - - - - - - - - - - - - - - - - - - - - - -|
  . | (indirected via UA)   |                      |
  . |                       |                      |
  . |                       |                      |
  +------------------------>|                      |
    |                       |                      |
    |                       |                      |
    |                       |3.0. Consumer requests|
    |                       |Access token, supplies|
    |                       |uRT.                  |
    |                       |--------------------->|
    |                       |                      |
    |                       |                      |
    |                       |                      |
    |                       |3.1. SP grants Access |
    |                       | Token.               |
    |                       |<---------------------|
    |                       |                      |
    |                       |                      |
    |                       |4.x. Consumer uses the|
    |                       |Access Token, Access  |
    |                       |Token Secret, Consumer|
    |                       |Key, and Consumer Secret
    |                       |to make authenticated |
    |                       |request(s) to the Service
    |                       |Provider.             |
    |                       |=====================>|
    |                       |           .          |
    |                       |           .          |
    |                       |           .          |
    |                       |                      |

My personal view is that this goes a bit against the OAUTH idea. Unless the
username/password is again created using some other mechanism (which the
document does not describe) then there are vulnerability that OAUTH was
initially meant to deal with. Additionally, the result is less likely to be
easy to deploy. 

As a justification for the work the following argument is provided: "HTTP
redirection to a browser is unavailable or unsuitable, such as intermediary
aggregators and mobile or settop devices." I wonder whether this is really a
problem in today's mobile devices to justify this optimization. 

Maybe I just didn't capture the idea properly.  

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Feb 2009 16:14:43 +0000

> draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in the

Actually, I sent a mail to you and Blaine off list. I guess
we should now discuss it on the list, now that you've gone
ahead here instead of responding to the off list mail.

Also I didn't ask how "its reflected" I suggested a way to
include it, which is quite different.

My suggestion is to add the following:

"The WG will develop an oauth extension suited for use
on challenged devices and by aggregators that allows for
the client to directly acquire an access token from
a set of credentials. One such scheme is defined in
draft-dehora-farrell-oauth-accesstoken-creds"

I'd still like to see that included and will certainly
suggest it again in SF, as I did in MSP, and without
anyone (that I recall) disagreeing with considering
the use case.

> extensions. 

Agreed. I never asked that our use case be worked before
the spec work is done and have no idea how you formed that
impression.

> As such, I would say that (depending on the progress of the work

I think its fair enough to mention the AFAIK only proposed extension
that's documented as an I-D in the charter. I don't read your current
charter proposal as encompassing our draft without rechartering.

> in the Access token when the Consumer sends the request to the Service

Right.

> initially meant to deal with. 

That's sort-of correct, however the point is that its necessary
to deploy OAuth for existing mobile devices and some aggregation
use cases.

> Additionally, the result is less likely to be
> easy to deploy. 

I think you're 100% wrong there...for the use cases we're
considering. On what basis do you say that? Do you think that
HTTP redirects on mobiles are just fine?

> problem in today's mobile devices to justify this optimization. 

You can wonder, but it is.

Stephen.

---

From: John Kemp <[email-masked]>
Date: Tue, 17 Feb 2009 14:22:14 -0500

> anyone (that I recall) disagreeing with considering

Personally I am in favour of working on such an extension, and if we  
need to update the charter to allow it, then I second Stephen's  
suggestion that we do so. .

> charter proposal as encompassing our draft without rechartering.

 From the charter text in [1]

> "After delivering OAuth, the Working Group may consider defining
> additional functions and/or extensions, for example (but not limited
> to):
>  * Discovery of authentication configuration.
>  * Message integrity.
>  * Recommendations regarding the structure of the token."

Perhaps we might add this proposal to that list explicitly?

Furthermore, is there a currently-known reason why we would wait to  
work on extensions until the OAuth specification itself is delivered,  
provided that there is the will and concrete support to create  
extensions?

There are several OAuth extensions already in use (language preference  
and problem reporting, to name a couple) and I would expect that since  
they are already in use by some, those people might wish also to  
revise them in light of an IETF-approved OAuth. Should these also be  
added explicitly?

[...]

> You can wonder, but it is.

I have to agree that multiple browser redirects in a mobile network  
are indeed still often a problem.

- johnk

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg00085.html

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 17 Feb 2009 22:12:29 +0200

Hi Stephen, 

adding the text as an example of possible extensions the group should work
on is fine for me as we have already listed other possible extensions to the
charter text. I got the impression that you wanted to have a milestone added
already, which I believe would be premature given that the main focus of the
initial work should be spent on the main spec. As I can read from your
response you are agreeing with me on this issue. 

I still believe that the document needs to provide much more context about
the usage scenarios you have in mind and what the implications regarding
security area. The current version of the document is essentially only
describing the bare minimum. 

Can you ship an update for the IETF#74 cutoff date?  

Ciao
Hannes

>> draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in 
>> the charter text.
>
>Actually, I sent a mail to you and Blaine off list. I guess we 
>should now discuss it on the list, now that you've gone ahead 
>here instead of responding to the off list mail.
>
>"The WG will develop an oauth extension suited for use on 
>challenged devices and by aggregators that allows for the 
>client to directly acquire an access token from a set of 
>credentials. One such scheme is defined in 
>I'd still like to see that included and will certainly suggest 
>it again in SF, as I did in MSP, and without anyone (that I 
>recall) disagreeing with considering the use case.
>
>> Independent of this particular document, I believe that we should 
>> focus our initial efforts on the Base OAUTH specification 
>rather than 
>> working on extensions.
>
>Agreed. I never asked that our use case be worked before the 
>spec work is done and have no idea how you formed that impression.
>
>> As such, I would say that (depending on the progress of the 
>work with 
>> the main specification) we should discuss extensions in the summer 
>> timeframe.
>
>I think its fair enough to mention the AFAIK only proposed 
>extension that's documented as an I-D in the charter. I don't 
>read your current charter proposal as encompassing our draft 
>without rechartering.
>
>> draft-dehora-farrell-oauth-accesstoken-creds-00.txt and 
>wanted to make 
>> sure that I understood the extension correctly. Here is a 
>message flow 
>> that Jeff created some time ago. This document suggests to skip the 
>> message exchanges marked as (2.*). This means that the redirect from 
>> the Service Provider to the Customer and the subsequent 
>steps of user 
>> authentication and authorization are replaced with the ability to 
>> carry some username/password in the Access token when the Consumer 
>> sends the request to the Service Provider.
>
>Right.
>
>> My personal view is that this goes a bit against the OAUTH idea. 
>> Unless the username/password is again created using some other 
>> mechanism (which the document does not describe) then there are 
>> vulnerability that OAUTH was initially meant to deal with.
>
>That's sort-of correct, however the point is that its 
>necessary to deploy OAuth for existing mobile devices and some 
>aggregation use cases.
>
>> Additionally, the result is less likely to be easy to deploy.
>
>> As a justification for the work the following argument is provided: 
>> "HTTP redirection to a browser is unavailable or unsuitable, such as 
>> intermediary aggregators and mobile or settop devices." I wonder 
>> whether this is really a problem in today's mobile devices 
>to justify this optimization.
>

---

From: <[email-masked]>
Date: Tue, 17 Feb 2009 21:43:07 +0100

I recall there was a lot of support in Minneapolis for extension targeted for devices as Stephen suggests.  I would support adding the text proposed by Stephen to the OAUTH charter:

"The WG will develop an oauth extension suited for use on challenged devices and by aggregators that allows for the client to directly acquire an access token from a set of credentials. One such scheme is defined in draft-dehora-farrell-oauth-accesstoken-creds"

I don't believe the last sentence precludes any other proposed drafts that meet this goal, if there are other approaches that may be developing in the WG.

Best Regards,
Dorothy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Stephen Farrell
Sent: Tuesday, February 17, 2009 8:15 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter

> draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in

Actually, I sent a mail to you and Blaine off list. I guess we should now discuss it on the list, now that you've gone ahead here instead of responding to the off list mail.

Also I didn't ask how "its reflected" I suggested a way to include it, which is quite different.

"The WG will develop an oauth extension suited for use on challenged devices and by aggregators that allows for the client to directly acquire an access token from a set of credentials. One such scheme is defined in draft-dehora-farrell-oauth-accesstoken-creds"

I'd still like to see that included and will certainly suggest it again in SF, as I did in MSP, and without anyone (that I recall) disagreeing with considering the use case.

> focus our initial efforts on the Base OAUTH specification rather than
> working on extensions.

Agreed. I never asked that our use case be worked before the spec work is done and have no idea how you formed that impression.

> As such, I would say that (depending on the progress of the work with

I think its fair enough to mention the AFAIK only proposed extension that's documented as an I-D in the charter. I don't read your current charter proposal as encompassing our draft without rechartering.

> draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make
> sure that I understood the extension correctly. Here is a message flow
> the Service Provider to the Customer and the subsequent steps of user

Right.

> vulnerability that OAUTH was initially meant to deal with.

That's sort-of correct, however the point is that its necessary to deploy OAuth for existing mobile devices and some aggregation use cases.

> Additionally, the result is less likely to be easy to deploy.

I think you're 100% wrong there...for the use cases we're considering. On what basis do you say that? Do you think that HTTP redirects on mobiles are just fine?

> whether this is really a problem in today's mobile devices to justify this optimization.

Stephen.

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 17 Feb 2009 14:07:07 -0700

I don't understand why we need to add this.

There is nothing to stop people from proposing and developing such ideas. So far we have little implementation experience with much of these suggestions. The fact is, everyone here is correctly referring to these ideas as *extensions*. The purpose of this working group is to figure out the 'core' framework. Error handling is crucial to interop. Internationalization is important when dealing with user interfaces which OAuth does even in its core components. These make sense to *consider*.

But why go and single out one extension just because it has an I-D? I could have stood up at the BoF and listed at least 10 other extensions with wide interest. Yahoo cares a lot about its Session extension. Google cares a lot about a few OpenSocial extensions related to gadgets. We have known limitations with the use of OAuth consumer credentials in desktop applications. Many people asked for a standard way of consumer registration. Discovery has been a big topic for the past year and a half. The choice of signature method hash functions have been an issue in the past due to lack to support for some on limited devices. The list goes on and on.

OAuth Core represents a compromise that allowed a wide range of use cases to agree on something that provided a good foundation and was based on implementation experience. For the most part this WG must have the narrow focus of taking draft-hammer-oauth and bringing it to IETF proposed standard level. That means focusing on security and interop. Anything else should come later.

EHL

On 2/17/09 12:43 PM, "[email-masked]" <[email-masked]> wrote:

Best Regards,
Dorothy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Stephen Farrell
Sent: Tuesday, February 17, 2009 8:15 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter

Right.

Stephen.

---

From: John Kemp <[email-masked]>
Date: Tue, 17 Feb 2009 16:21:00 -0500

On Feb 17, 2009, at 4:07 PM, Eran Hammer-Lahav wrote:

> I don’t understand why we need to add this.
>
> There is nothing to stop people from proposing and developing such  
> ideas. So far we have little implementation experience with much of  
> these suggestions. The fact is, everyone here is correctly referring  
> to these ideas as *extensions*. The purpose of this working group is  
> to figure out the ‘core’ framework. Error handling is crucial to  
> interop. Internationalization is important when dealing with user  
> interfaces which OAuth does even in its core components. These make  
> sense to *consider*.
>
> But why go and single out one extension just because it has an I-D?

My answer would be simply that a list of proposed "extensions" is  

>> * Recommendations regarding the structure of the token."

I could be persuaded that this text doesn't prevent the development of  
any extensions, but once you list one, you run the risk of people  
asking "why don't you list XYZ too?"

> I could have stood up at the BoF and listed at least 10 other  
> extensions with wide interest. Yahoo cares a lot about its Session  
> extension. Google cares a lot about a few OpenSocial extensions  
> related to gadgets. We have known limitations with the use of OAuth  
> consumer credentials in desktop applications. Many people asked for  
> a standard way of consumer registration. Discovery has been a big  
> topic for the past year and a half. The choice of signature method  
> hash functions have been an issue in the past due to lack to support  
> for some on limited devices. The list goes on and on.
>
> OAuth Core represents a compromise that allowed a wide range of use  
> cases to agree on something that provided a good foundation and was  
> based on implementation experience. For the most part this WG must  
> have the narrow focus of taking draft-hammer-oauth and bringing it  
> to IETF proposed standard level. That means focusing on security and  
> interop. Anything else should come later.

I don't think timing is so much the issue.

Regards,

- johnk

>
>
> EHL
>
>
> On 2/17/09 12:43 PM, "[email-masked]" <[email-masked] 
> > wrote:
>
>
>
> I recall there was a lot of support in Minneapolis for extension  
> targeted for devices as Stephen suggests.  I would support adding  
> the text proposed by Stephen to the OAUTH charter:
>
> "The WG will develop an oauth extension suited for use on challenged  
> devices and by aggregators that allows for the client to directly  
> acquire an access token from a set of credentials. One such scheme  
> is defined in draft-dehora-farrell-oauth-accesstoken-creds"
>
> I don't believe the last sentence precludes any other proposed  
> drafts that meet this goal, if there are other approaches that may  
> be developing in the WG.
>
> Best Regards,
> Dorothy
>
>
> Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken- 
> creds-00.txt and OAUTH Extensions in the Charter
>
>
>
> Hannes Tschofenig wrote:
> should now discuss it on the list, now that you've gone ahead here  
> instead of responding to the off list mail.
>
> "The WG will develop an oauth extension suited for use on challenged  
> devices and by aggregators that allows for the client to directly  
> acquire an access token from a set of credentials. One such scheme  
> is defined in draft-dehora-farrell-oauth-accesstoken-creds"
>
> I'd still like to see that included and will certainly suggest it  
> again in SF, as I did in MSP, and without anyone (that I recall)  
> disagreeing with considering the use case.
>
> Agreed. I never asked that our use case be worked before the spec  
> work is done and have no idea how you formed that impression.
>
> with
> that's documented as an I-D in the charter. I don't read your  
> current charter proposal as encompassing our draft without  
> rechartering.
>
> That's sort-of correct, however the point is that its necessary to  
> deploy OAuth for existing mobile devices and some aggregation use  
> cases.
>
> considering. On what basis do you say that? Do you think that HTTP  
> redirects on mobiles are just fine?
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 17 Feb 2009 14:33:02 -0700

Listing a bunch of ideas the WG might want to consider later on is fine by me (and pretty useless). The charter is suppose to help us focus...

EHL

On 2/17/09 1:21 PM, "John Kemp" <[email-masked]> wrote:

On Feb 17, 2009, at 4:07 PM, Eran Hammer-Lahav wrote:

> to figure out the 'core' framework. Error handling is crucial to

Regards,

- johnk

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 17 Feb 2009 23:36:46 +0200

Hi Eran, 
 
I understand your concerns. We started to add examples to the initial
charter text: 
 
"
After delivering OAuth, the Working Group may consider defining additional
functions and/or extensions, for example (but not limited to):

* Discovery of authentication configuration.
* Message integrity.
* Recommendations regarding the structure of the token.
"

I understand why Stephen asks for getting text about his extension added. I
can imagine that someone else comes up with their favorite extension,
simililarly as you listed in your mail. 

In some sense it would be fair to add text about the other examples added as
well, if someone cares. 

I wonder what other folks in the group think about this topic? 

Ciao
Hannes

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eran Hammer-Lahav
	Sent: 17 February, 2009 23:07
	To: [email-masked]; [email-masked];
[email-masked]
	Cc: [email-masked]
	Subject: Re: [oauth]
draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in
the Charter

	There is nothing to stop people from proposing and developing such
ideas. So far we have little implementation experience with much of these
suggestions. The fact is, everyone here is correctly referring to these
ideas as *extensions*. The purpose of this working group is to figure out
the 'core' framework. Error handling is crucial to interop.
Internationalization is important when dealing with user interfaces which
OAuth does even in its core components. These make sense to *consider*.
	
	But why go and single out one extension just because it has an I-D?
I could have stood up at the BoF and listed at least 10 other extensions
with wide interest. Yahoo cares a lot about its Session extension. Google
cares a lot about a few OpenSocial extensions related to gadgets. We have
known limitations with the use of OAuth consumer credentials in desktop
applications. Many people asked for a standard way of consumer registration.
Discovery has been a big topic for the past year and a half. The choice of
signature method hash functions have been an issue in the past due to lack
to support for some on limited devices. The list goes on and on.
	
	OAuth Core represents a compromise that allowed a wide range of use
cases to agree on something that provided a good foundation and was based on
implementation experience. For the most part this WG must have the narrow
focus of taking draft-hammer-oauth and bringing it to IETF proposed standard
level. That means focusing on security and interop. Anything else should
come later.
	
	EHL

	On 2/17/09 12:43 PM, "[email-masked]"
<[email-masked]> wrote:

		
		I recall there was a lot of support in Minneapolis for
extension targeted for devices as Stephen suggests.  I would support adding
the text proposed by Stephen to the OAUTH charter:
		
		"The WG will develop an oauth extension suited for use on
challenged devices and by aggregators that allows for the client to directly
acquire an access token from a set of credentials. One such scheme is
defined in draft-dehora-farrell-oauth-accesstoken-creds"
		
		I don't believe the last sentence precludes any other
proposed drafts that meet this goal, if there are other approaches that may
be developing in the WG.
		
		Best Regards,
		Dorothy

		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Stephen Farrell
		Sent: Tuesday, February 17, 2009 8:15 AM
		To: Hannes Tschofenig
		Cc: [email-masked]
		Subject: Re: [oauth]
draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in
the Charter

		
		Actually, I sent a mail to you and Blaine off list. I guess
we should now discuss it on the list, now that you've gone ahead here
instead of responding to the off list mail.

		
		"The WG will develop an oauth extension suited for use on
challenged devices and by aggregators that allows for the client to directly
acquire an access token from a set of credentials. One such scheme is
defined in draft-dehora-farrell-oauth-accesstoken-creds"
		
		I'd still like to see that included and will certainly
suggest it again in SF, as I did in MSP, and without anyone (that I recall)
disagreeing with considering the use case.
		
rather than

		
		I think its fair enough to mention the AFAIK only proposed
extension that's documented as an I-D in the charter. I don't read your
current charter proposal as encompassing our draft without rechartering.
		
wanted to make
message flow
steps of user
		
		Right.

		That's sort-of correct, however the point is that its
necessary to deploy OAuth for existing mobile devices and some aggregation
use cases.

		I think you're 100% wrong there...for the use cases we're
considering. On what basis do you say that? Do you think that HTTP redirects
on mobiles are just fine?

		
		Stephen.

---

From: Blaine Cook <[email-masked]>
Date: Tue, 17 Feb 2009 21:57:55 +0000

Can I suggest that we update the section of the charter before the
Goals and Milestones that currently reads:

After delivering OAuth, the Working Group MAY consider defining
additional functions and/or extensions, for example (but not limited
to):
* Discovery of authentication configuration
* Message integrity
* Recommendations regarding the structure of the token

to read:

After delivering OAuth, the Working Group MAY consider defining
additional functions and/or extensions, for example (but not limited
to):
* Discovery of OAuth configuration
* Comprehensive message integrity
* Recommendations regarding the structure of the token
* Localization
* Error reporting
* Session-oriented tokens
* Alternate token exchange profiles

Note also that the list is not bounded, and I expect that any work
done after the finalization of OAuth as per the charter will happen
only insofar as running exemplar code exists and can serve as a basis
for standardization driven by actual involvement from the community.

Does that satisfy the requirements? I definitely echo Eran's concerns
that our primary task is the Core specification, but want to make sure
that everyone has clear expectations and feels that they can make
valuable contributions going in.

cheers,

b.

---

From: Blaine Cook <[email-masked]>
Date: Tue, 17 Feb 2009 22:30:08 +0000

One slight modification, as per an off-list conversation with Eran:

move " * Error reporting" from extensions, and incorporate that work
into the core spec, which I believe was agreed upon in principle
several months ago at the start of this process. I don't think we need
to modify the charter text, as error reporting would fall under the
requirement to "promote interoperability", though we can add it
explicitly if it makes sense.

b.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Feb 2009 23:39:52 +0000

> simililarly as you listed in your mail. 

Right. This being the IETF, taking the trouble to write an
I-D, boilerplate and all, counts, As does code. But one
without the other is less good than having both.

> In some sense it would be fair to add text about the other examples added as

Yes, folks writing drafts is a good idea. By all means include
mention of topics with I-Ds.

> I wonder what other folks in the group think about this topic? 

You can guess from the above - gate the list (for now) based on who's
written up their stuff as an I-D. Doesn't preclude additions later
but does require some work before getting on the list in the
charter.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Feb 2009 23:44:00 +0000

Sounds good. I'll see if we've the cycles to get a -01 out (and
totally agree that -00 is missing an important applicability
statement - we did however submit -00 in the 10 minutes before
the MSP deadline, hence the omission:-)

As to milestones, yes, I'd prefer that the charter have a
milestone for draft-ietf-oauth-mobile-00 being 3-6 months
after the WGLC on the base spec. But I can buy the idea of
just mentioning the topic and re-doing the milestones after
WGLC on the base spec.

Stephen.