Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)

[George Fletcher <[e-mail]>]

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:
> 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:[e-mail]
> Desk in Palo Alto: [phone]
> Home: [phone]
> Cell: [phone]
>
>
> -----Original Message-----
> From:[e-mail]  [mailto:[e-mail]] On Behalf Of Mike Jones
> Sent: Wednesday, October 27, 2010 9:57 AM
> To: Hannes Tschofenig; Blaine Cook;[e-mail]
> Subject: Re: [OAUTH-WG] Call for Consensus on Document Split
>
> 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:[e-mail]  [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, October 27, 2010 4:34 AM
> To: Blaine Cook;[e-mail]
> 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
>
> On 10/14/10 3:32 AM, "Blaine Cook"<[e-mail]>  wrote:
>
>> 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
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>