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:[email protected]
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-7536
-----Original Message-----
From:[email protected] [mailto:[email protected]] On Behalf Of Mike
Jones
Sent: Wednesday, October 27, 2010 9:57 AM
To: Hannes Tschofenig; Blaine Cook;[email protected]
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:[email protected] [mailto:[email protected]] On Behalf Of
Hannes Tschofenig
Sent: Wednesday, October 27, 2010 4:34 AM
To: Blaine Cook;[email protected]
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"<[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
