Subject: [OAUTH-WG] Call for Consensus on Document Split

From: Blaine Cook <[email-masked]>
Date: Wed, 13 Oct 2010 17:32:20 -0700

Over the past few weeks, the working group debated the issues around
the introduction of signatures and the structure of the specification.
The working group seems to endorse the proposal to split the current
specification into two parts: one including section 5 (bearer token)
and the other including the rest (how to obtain a token), with an
additional specification covering signature use cases.

This serves as a call for consensus on the proposed editorial work.
Before we proceed with the changes, the chairs would like to ask if
anyone has any concerns or objections against this proposal.

In addition, the chairs are seeking a volunteer to take over the
bearer token specification (section 5) as editor.

Please submit your comments by Wednesday, October 20th.

- The OAuth Working Group Chairs

---

From: Mike Jones <[email-masked]>
Date: Thu, 14 Oct 2010 07:06:39 +0000

I am willing to serve as editor for the bearer token specification and have my management's approval to do so.  Furthermore, I believe that I am qualified, having successfully served as an editor for several standards specifications, including the OASIS IMI specification and related SAML token profiles, the OpenID PAPE specification, and (some time ago), the POSIX Threads standard.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Wednesday, October 13, 2010 5:32 PM
To: [email-masked]
Subject: [OAUTH-WG] Call for Consensus on Document Split

Over the past few weeks, the working group debated the issues around the introduction of signatures and the structure of the specification.
The working group seems to endorse the proposal to split the current specification into two parts: one including section 5 (bearer token) and the other including the rest (how to obtain a token), with an additional specification covering signature use cases.

This serves as a call for consensus on the proposed editorial work.
Before we proceed with the changes, the chairs would like to ask if anyone has any concerns or objections against this proposal.

In addition, the chairs are seeking a volunteer to take over the bearer token specification (section 5) as editor.

- The OAuth Working Group Chairs
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 15 Oct 2010 10:19:36 +1100

Blaine,

I am in favour of splitting the specification, but the right dividing line is not the whole of section 5 "Accessing a Protected Resource".

The core OAuth spec needs to keep a section defining a WWW-Authenticate response header with which to tell a client that the OAuth "get a token" flows can be used to get access to a resource. This is a bit like section 5.2 "The WWW-Authenticate Response Header Field".

Error codes [section 5.2] like "expired_token" or "insufficient_scope" only make sense in a spec that defines the flows to renew a token or change its scope. I assume that will be the core OAuth spec, not the bearer token spec. For comparison, the HTTP BASIC spec does not tell you how to change your password or register for a password.

My suggestion for the editorial split:
* Remove 5, 5.1, 5.1.1, 5.1.2, and 5.1.3.
* Keep 5.2, and 5.2.1.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Oct 2010 21:38:46 -0700

This was the proposal posted to the group earlier.

In the past you have strongly promoted separate schemes for each token type, as well as rejected the idea of a single scheme framework with sub-typing. How would you suggest we define a general purpose www-authenticate header that does not have a matching request header?

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Manger, James H
> Sent: Thursday, October 14, 2010 4:20 PM
> To: Blaine Cook; [email-masked]
> Subject: Re: [OAUTH-WG] Call for Consensus on Document Split
> 
> Blaine,
> 
> I am in favour of splitting the specification, but the right dividing line is not
> the whole of section 5 "Accessing a Protected Resource".
> 
> The core OAuth spec needs to keep a section defining a WWW-Authenticate
> response header with which to tell a client that the OAuth "get a token"
> flows can be used to get access to a resource. This is a bit like section 5.2 "The
> WWW-Authenticate Response Header Field".
> 
> Error codes [section 5.2] like "expired_token" or "insufficient_scope" only
> make sense in a spec that defines the flows to renew a token or change its
> scope. I assume that will be the core OAuth spec, not the bearer token spec.
> For comparison, the HTTP BASIC spec does not tell you how to change your
> password or register for a password.
> 
> 
> Over the past few weeks, the working group debated the issues around the
> introduction of signatures and the structure of the specification.
> specification into two parts: one including section 5 (bearer token) and the
> other including the rest (how to obtain a token), with an additional
> specification covering signature use cases.
> 
> Before we proceed with the changes, the chairs would like to ask if anyone
> has any concerns or objections against this proposal.
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 15 Oct 2010 16:10:25 +1100

Eran,

> How would you suggest we define a general purpose www-authenticate
> header that does not have a matching request header?

Why would that be a problem?
We define what a "WWW-Authenticate: OAuth2 ..." response header means, but don't define any meaning for a "Authorization: OAuth2 ..." request header.
No other scheme should define a meaning for "Authorization: OAuth2 ...".
Consequently, the bearer token spec need to choose a different scheme name (eg "BEARER" or "TOKEN" or "EXTERNAL") so it can define request & response headers.

There is even some precedent for this. draft-broyer-http-cookie-auth defines "WWW-Authenticate: COOKIE ...", without any matching request header.
I think there have also been ideas to define something like "WWW-Authenticate: TLS ..." to indicate when authentication at a lower layer (TLS, IPsec) is required. Again there was no matching "Authorization: TLS ..." header.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 14 Oct 2010 22:30:31 -0700

I have no objection to this if it passes the smell test by some HTTP experts. I'll ask.

EHL

> Sent: Thursday, October 14, 2010 10:10 PM
> To: [email-masked]
> We define what a "WWW-Authenticate: OAuth2 ..." response header
> means, but don't define any meaning for a "Authorization: OAuth2 ..."
> request header.
> Consequently, the bearer token spec need to choose a different scheme
> name (eg "BEARER" or "TOKEN" or "EXTERNAL") so it can define request &
> response headers.
> 
> There is even some precedent for this. draft-broyer-http-cookie-auth
> defines "WWW-Authenticate: COOKIE ...", without any matching request
> header.
> I think there have also been ideas to define something like "WWW-
> Authenticate: TLS ..." to indicate when authentication at a lower layer (TLS,
> IPsec) is required. Again there was no matching "Authorization: TLS ..."
> header.
> 
> --
> James Manger
>

---

From: Brian Eaton <[email-masked]>
Date: Wed, 20 Oct 2010 10:13:34 -0700

On Thu, Oct 14, 2010 at 12:06 AM, Mike Jones
<[email-masked]> wrote:
> I am willing to serve as editor for the bearer token specification and have my
> management's approval to do so.  Furthermore, I believe that I am qualified,
> having successfully served as an editor for several standards specifications,
> including the OASIS IMI specification and related SAML token profiles, the
> OpenID PAPE specification, and (some time ago), the POSIX Threads standard.

Thanks Mike!  This sounds great.

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 20 Oct 2010 11:54:56 -0700

+1

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 20 Oct 2010 22:56:35 -0700

This is not a comment about Mike's generous offer.

Choosing an editor is the sole discretion of the chairs. While the working group can offer the chairs feedback, it is best done directly because of the personal nature of selecting people. At the end, the chairs choose the person they want for the role. I just want to make sure people understand how this works, and to avoid debating roles in the same way we argue about technical details.

EHL

> Of Marius Scurtescu
> Sent: Wednesday, October 20, 2010 11:55 AM
> To: Mike Jones
> Cc: [email-masked]
> > I am willing to serve as editor for the bearer token specification and have
> my management's approval to do so.  Furthermore, I believe that I am
> qualified, having successfully served as an editor for several standards
> specifications, including the OASIS IMI specification and related SAML token
> profiles, the OpenID PAPE specification, and (some time ago), the POSIX
> Threads standard.
> >
> >                                -- Mike
> >
> > Of Blaine Cook
> > In addition, the chairs are seeking a volunteer to take over the bearer
> token specification (section 5) as editor.
> >

---

From: Blaine Cook <[email-masked]>
Date: Wed, 20 Oct 2010 23:26:20 -0700

On that process note, does anyone OBJECT to splitting the draft as
described? The call closes in about an hour, depending on which time
zone you're in. If we don't hear objections by mid-day PST tomorrow
(the 21st), I think it's safe to say we have consensus on this issue.

b.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Oct 2010 14:34:12 +0300

Hi all, 

based on the feedback from the group on the list we go forward with the
document split. 

Mike had kindly offered to edit the bearer specification and we are happy to
hear that. Thank you Mike. I am looking forward to see the first document.

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Wed, 27 Oct 2010 16:56:50 +0000

Thanks for your confidence in me.  I look forward to completing a specification that meets the industry needs.

I plan to sync with Eran this week.  I also plan to hold a "listening tour" at IIW to understand stakeholders' perspectives on where we stand with OAuth 2.0 today and what remains to do finish it.  Please come talk to me at IIW if you're there and you're building or deploying OAuth 2.0 and want me to understand your views.  E-mail and phone calls are also welcome.

Once I've synced with Eran and gathered input from stakeholders, I'll plan on announcing target dates for drafts.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, October 27, 2010 4:34 AM
To: Blaine Cook; [email-masked]
Subject: Re: [OAUTH-WG] Call for Consensus on Document Split

Hi all, 

based on the feedback from the group on the list we go forward with the document split. 

Mike had kindly offered to edit the bearer specification and we are happy to hear that. Thank you Mike. I am looking forward to see the first document.

Ciao
Hannes

---

From: "Freeman, Tim" <[email-masked]>
Date: Wed, 27 Oct 2010 18:09:23 +0000

On the face of it, it seems that discussion of whether and how to split the document has derailed collection of use cases.  If we had consensus on a list of use cases, that would mean we have identified the problems we're trying to solve.  This would still allow slimy political manipulation of the process by manipulating the use case list, but that would be progress.  It's better to have a protocol that solves a politically-defined set of problems than to have a politically-defined protocol that solves no identified problem.

It's also possible that such collection is going on via private email and I am not aware of it.

The questions currently interesting to me about use cases are:

* The only use cases that made sense to me about signatures used them for auditability, where they enabled blame to be properly placed after information leaked to the wrong people.  People were proposing use cases that claimed that signatures improved privacy, that is, the ability to keep the information out of the hands of the wrong people.  So far as I know all use cases where signatures improved privacy seemed to fall apart after a few minutes inspection.  Do we agree that signatures improve auditability but not privacy, or does someone still believe in a use case where signatures improve privacy?

* Use cases that justify a feature seem to require two parts -- an example where the feature is absent and therefore a particular problem cannot be solved, and an example where the feature is present and the same problem can then be solved.  Last I checked the existing use case list seemed to only have the second type where problems were successfully solved and it was unclear to me that the proposed features were really required in order to do that.  Do we agree that justifying a feature requires both a use case where absence of the feature makes a problem unsolvable and presence of the feature makes the same problem solvable?  (Alternatives are to believe that there is some other way to justify having a feature, or to believe we should have features that do not have a clearly described technical justification.  Maybe the features are required by law, are esthetically pleasing, make use of the right patents and not the wrong ones, look impressive on one's resume, etc.)

* The simplest signature schemes seem have the consequence of preventing server A from delegating work to server B, since the work must be done by making requests signed by server A.  Do we want to support use cases where one server delegates work to another server?  Do we want to do by allowing A's right to do certain things to be traded in for something that gives B the right to do some of those things, by bearer tokens, by some other means, or not at all?

Tim Freeman
Email: [email-masked]
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-7536

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, October 27, 2010 9:57 AM
To: Hannes Tschofenig; Blaine Cook; [email-masked]
Subject: Re: [OAUTH-WG] Call for Consensus on Document Split

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, October 27, 2010 4:34 AM
To: Blaine Cook; [email-masked]
Subject: Re: [OAUTH-WG] Call for Consensus on Document Split

Hi all, 

Ciao
Hannes

---

From: William Mills <[email-masked]>
Date: Wed, 27 Oct 2010 11:40:42 -0700

Another use case for signatures is gross management of relationships, controlling the secrets in use for (I'll misuse the term) peers allows a single point of control for that relationship.

> Of Freeman, Tim
> Sent: Wednesday, October 27, 2010 11:09 AM
> To: [email-masked]
> Subject: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus
> on Document Split)
> 
> On the face of it, it seems that discussion of whether and how to split
> the document has derailed collection of use cases.  If we had consensus
> on a list of use cases, that would mean we have identified the problems
> we're trying to solve.  This would still allow slimy political
> manipulation of the process by manipulating the use case list, but that
> would be progress.  It's better to have a protocol that solves a
> politically-defined set of problems than to have a politically-defined
> protocol that solves no identified problem.
> 
> * The only use cases that made sense to me about signatures used them
> for auditability, where they enabled blame to be properly placed after
> information leaked to the wrong people.  People were proposing use
> cases that claimed that signatures improved privacy, that is, the
> ability to keep the information out of the hands of the wrong people.
> So far as I know all use cases where signatures improved privacy seemed
> to fall apart after a few minutes inspection.  Do we agree that
> signatures improve auditability but not privacy, or does someone still
> believe in a use case where signatures improve privacy?
> 
> * Use cases that justify a feature seem to require two parts -- an
> example where the feature is absent and therefore a particular problem
> cannot be solved, and an example where the feature is present and the
> same problem can then be solved.  Last I checked the existing use case
> list seemed to only have the second type where problems were
> successfully solved and it was unclear to me that the proposed features
> were really required in order to do that.  Do we agree that justifying
> a feature requires both a use case where absence of the feature makes a
> problem unsolvable and presence of the feature makes the same problem
> solvable?  (Alternatives are to believe that there is some other way to
> justify having a feature, or to believe we should have features that do
> not have a clearly described technical justification.  Maybe the
> features are required by law, are esthetically pleasing, make use of
> the right patents and not the wrong ones, look impressive on one's
> resume, etc.)
> 
> * The simplest signature schemes seem have the consequence of
> preventing server A from delegating work to server B, since the work
> must be done by making requests signed by server A.  Do we want to
> support use cases where one server delegates work to another server?
> Do we want to do by allowing A's right to do certain things to be
> traded in for something that gives B the right to do some of those
> things, by bearer tokens, by some other means, or not at all?
> 
> Tim Freeman
> Of Mike Jones
> Thanks for your confidence in me.  I look forward to completing a
> specification that meets the industry needs.
> 
> I plan to sync with Eran this week.  I also plan to hold a "listening
> tour" at IIW to understand stakeholders' perspectives on where we stand
> with OAuth 2.0 today and what remains to do finish it.  Please come
> talk to me at IIW if you're there and you're building or deploying
> OAuth 2.0 and want me to understand your views.  E-mail and phone calls
> are also welcome.
> 
> Once I've synced with Eran and gathered input from stakeholders, I'll
> plan on announcing target dates for drafts.
> 
> 				-- Mike
> 
> Of Hannes Tschofenig
> Mike had kindly offered to edit the bearer specification and we are
> happy to hear that. Thank you Mike. I am looking forward to see the
> first document.
> 
> Ciao
> Hannes
>

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Wed, 27 Oct 2010 14:27:38 -0500

>* Use cases that justify a feature seem to require two parts -- an example >where the feature is absent and therefore a particular problem cannot be >solved, and an example where the feature is present and the same problem >can then be solved.

There are use cases that can be supported by more than one solution. For example, the use case specified in the original OAuth specifications (authorizing a client to print private photos) relies on the signature-based solutions. The same use case in OAuth 2.0 -v10 (Web Server) is supported by a solution that does not use signatures, but requires to use TLS.
So, the same problem is solved in two different ways and each solution justifies different features.

Zachary
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Freeman, Tim
Sent: Wednesday, October 27, 2010 2:09 PM
To: [email-masked]
Subject: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)

Tim Freeman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, October 27, 2010 9:57 AM
To: Hannes Tschofenig; Blaine Cook; [email-masked]
Subject: Re: [OAUTH-WG] Call for Consensus on Document Split

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, October 27, 2010 4:34 AM
To: Blaine Cook; [email-masked]
Subject: Re: [OAUTH-WG] Call for Consensus on Document Split

Hi all, 

Ciao
Hannes

---

From: Skylar Woodward <[email-masked]>
Date: Wed, 27 Oct 2010 23:41:58 +0200

> * The only use cases that made sense to me about signatures used them for auditability, where they enabled blame to be properly placed after information leaked to the wrong people.  People were pro…

For Kiva, our use case would be something along the lines of "secondary protection mechanism."   To access certain types of data we want client authentication (ie, identification) to request and use tokens. The specification w/o signatures depends only on SSL to protect secrets, passwords, and tokens and thus client identity. By requesting signed requests we have a second mechanism on top of SSL to protect secrets in the event that request is leaked to an improper endpoint - as secrets are never sent over the wire. To reuse some of Zachary's language, we're combining two solutions to solve one problem.

We agree of course, that SSL, properly used - with no human error, is enough to secure the secrets between the two parties. However, secondary protection mechanisms are popular in the financial world - site keys, RSA fobs, shared secrets, IP-filtering, SMS-issued pins. Though any one mechanism is enough, a second mechanism makes things even more difficult for clever attackers (and careless developers). Given the options available to us, shared secrets confirmed though the use of signatures offer the most attractive balance of protection vs. ease of deployment (many of our partners are in developing countries which offer logistical and technological challenges to other methods).

That said, I don't advocate requiring signatures as a part of the spec (our needs/preferences are possibly too unique?), but I would like them included. Thus, if some non-political use cases drive signatures to be added, we'd certainly like to adopt the common standard. In lack of a published standard for signatures, we'll add our own layer additional layers of protection onto the spec as others have done. (OAuth 1.0a signatures suit us in lack of a simpler new standard for 2.0, especially given the amount of published works related to doing them correctly.)

skylar

---

From: George Fletcher <[email-masked]>
Date: Wed, 27 Oct 2010 22:01:55 -0400

I'm not sure what you mean by signatures improving privacy? I don't see 
signature having much effect on privacy. Encryption is needed for that.

However, signatures do limit the scope of exposure should a token get 
exposed in some manner. In that sense a user is protected because a 
leaked token isn't usable accept by the party to which it was issued.

I also believe that signatures are orthogonal to the delegation use 
case. In other words, signatures don't prevent server A from getting a 
token and giving it to server B for server B to use with a protected 
resource.

Thanks,
George

On 10/27/10 2:09 PM, Freeman, Tim wrote:
> Email:[email-masked]
> From:[email-masked]  [mailto:[email-masked]] On Behalf Of Mike Jones
> To: Hannes Tschofenig; Blaine Cook;[email-masked]
> From:[email-masked]  [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> To: Blaine Cook;[email-masked]
> On 10/14/10 3:32 AM, "Blaine Cook"<[email-masked]>  wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Oct 2010 14:04:35 +0300

Hey Tim, 

Earlier this year we had discussions around use cases but they did not lead
to more insight. 

There is a document in the draft repository that talks about use cases,
namely 
http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/
But it had never gotten a lot of attention on the list. (I don't know why.)

Efforts to reach out to the Kantara UMA group for more sophisticated uses
cases that motivate some security mechanisms have not produced anything
either. (I believe the reason was that the scenarios focused on the
user-experience aspect rather than on security differences.)

If you look at the draft that Blaine and I put together recently (see
http://datatracker.ietf.org/doc/draft-tschofenig-oauth-signature-thoughts/
) then you will notice that from a security point of view there is very
little difference between using message signing on the HTTP layer and using
TLS with respect to a certain class of security threats.

In our recommendation we actually suggest to  recommend to go for the HTTP
layer security because we are worried that ***operational*** aspects will go
wrong in deployments.

While I was convinced initially that looking at the use cases will get us
further on the security questions it actually does not.

Ciao
Hannes

PS: Btw, your feedback on the security draft would be of interest to us.

On 10/27/10 9:09 PM, "ext Freeman, Tim" <[email-masked]> wrote:

> On the face of it, it seems that discussion of whether and how to split the
> document has derailed collection of use cases.  If we had consensus on a list
> of use cases, that would mean we have identified the problems we're trying to
> solve.  This would still allow slimy political manipulation of the process by
> manipulating the use case list, but that would be progress.  It's better to
> have a protocol that solves a politically-defined set of problems than to have
> a politically-defined protocol that solves no identified problem.

---

From: Eve Maler <[email-masked]>
Date: Thu, 28 Oct 2010 08:10:25 -0700

Hi Hannes,

Regarding UMA's "security use cases", indeed we haven't been producing formal use cases in a form that readily maps to what this group is looking for.  However, I've reproduced below the comments I sent you privately on your OAuth signature thoughts doc (too late for your IETF submission editing round); they contain specific descriptions and pointers to a major security requirement of UMA that relates to this discussion.

	Eve

====

- The Alice/Bob/Carol language is a bit distracting.  I kept scribbling "authz server" etc. on my copy to make sure I had it straight. Given that you're talking about OAuth specifically, do you think using real OAuth terminology would be okay?

- (Nit:) At the bottom of page 2, I couldn't understand "...and in managing a resource that is work delegating access to."

- I think there's a threat missing, something like "token replay" (but that doesn't seem quite right).  This is where the Alice language is holding me back!  If Alice == client, the token might be stolen by a malicious client Eve (or Alice might maliciously give it to Eve to use), then used at Bob as if Eve were Alice.  Naming all the threats "token <something>" makes it hard to decide what to call it, but left to my own devices I'd call it "client correlation".  OAuth seems to want to put this out of scope, but it's a real problem for UMA, given that our authorization server and resource server might be in different administrative domains.  You can see the problem statement here:

http://groups.google.com/group/kantara-initiative-uma-wg/browse_frm/thread/cafa098084c7c208/703617741a124124?lnk=gst&q=step+3#703617741a124124

...and our current (very constrained and signature-free!) solution in Step 3 here:

http://mrtopf.clprojects.net/uma/draft-uma-core.html

One of the reasons we want to be able to point to/build on an OAuth signing solution is that a short token lifetime isn't very performant/scalable.  But we're inclined to leave our simple solution in place as mandatory-to-implement.

- Another thing that's probably worth observing is that OAuth thinks of a token as either containing real assertions or being an artifact that can be referenced to get to assertions.  But UMA's treatment is entirely consistent too: a token stands for an authorization decision, with all the specifics of assertions/claims pushed exclusively to the Alice/Carol (client/authz server) communication.

>> a politically-defined protocol that solves no identified problem.

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 28 Oct 2010 14:46:30 -0500

Hanes,

>...
>namely http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/

Actually, there is a good news here: We've got 13 queries on the list (in addition to some private ones) with constructive suggestions, and we are working with Torsten on incorporating all of them. In particular, the next issue of the draft will include George's use case submitted recently.

Furthermore, as WAC community is looking at OAuth, we will soon have a WAC use case (or a set of use cases).

So, I am pretty happy with the attention level: we get positive contribution while not getting disruption.

As for specific security issues, I think up to now we dealt with a different problem: Our use cases have reflected authentication requirements, but concentrated on the use scenarios (which protocol features should reflect) rather than dealing with specific threats that affecting the features. This specific work will be coming from Torsten.

I am not sure whether the use case document should delve in security detail, except for cases (such as payment) that in themselves dictate the protection level. As Igor wrote, security requirements for accessing health records are very different from those for accessing photos on Flickr.  

This is what I hope we can discuss at the meeting--formal or informal--in 10 days.
I am open to all suggestions.

Zachary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, October 28, 2010 7:05 AM
To: ext Freeman, Tim; [email-masked]
Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)

Hey Tim, 

Ciao
Hannes