Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
Sounds great Eran,
1. Add a parameter to the token response to include an extensible token
scheme.
Yes. I suggest a parameter named scheme. The value can be an HTTP
authentication scheme name (eg scheme:BASIC) for which the response is
providing credentials. Not all possibilities are HTTP authentication schemes
but they can be assigned pseudo-HTTP-auth-scheme-names (eg scheme:TLS-PSK).
The default (if omitted) will be whatever the bearer token scheme is called.
May as well include the bearer token scheme name (ie don't bother with a
default). Might even be convenient to use the scheme name as a JSON key in a
token response.
credentials:{
bearer:{token:54er},
basic:{userid:jim,password:beer2} }
2. Break the core specification into multiple parts.
Yes. Hopefully the using a token parts don't have to be OAuth-specific. They
might not even use the term token. A signature spec could use an id and
key, without caring whether or not those items came from a getting a token
response or from a config file.
3. Introduce two signature proposals in one or more documents, for the JSON
token and 1.0a-like method.
Yes. Separate docs for each signature proposal sounds best to me.
--- Benefits
2. Solve a few open issues:
* The need to decide on discovery for the entire protocol (moves it to each
scheme).
I don't think it removes much of the need for discovery.
Apps still need to discover that OAuth delegation can be used to access a
resource (and where to send the user). I suspect the token response performs
some of the discovery related to specific schemes (eg the response says here
is a token to use with the 'BEARER' scheme, or here is an id for this
delegation and a secret to used in signature scheme XYZ.
--
James Manger
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Basic signature support in the core specification
Yes, I'm willing to write guides for the profiles that I use, once things settle down and we know what the protocol actually is. :) I'd argue that Facebook's developer docs are a start for bearer tokens using the UX extension and web server/user agent profiles already. I think that the most sensible place to put things like this would be the oauth.net wiki. -- Justin On Tue, 2010-09-28 at 00:48 -0400, Eran Hammer-Lahav wrote: Are you going to write it? Still waiting for the best practices guide for 1.0 people suggested over three years ago. EHL -Original Message- From: Justin Richer [mailto:jric...@mitre.org] Sent: Monday, September 27, 2010 12:04 PM To: Eran Hammer-Lahav Cc: Dick Hardt; OAuth WG Subject: Re: [OAUTH-WG] Basic signature support in the core specification Arguments like this are why I have been advocating for separating the developers guide from the protocol spec for a while now. I believe that they support two different audiences. A developers' guide then has the option of combining multiple specs, selecting profiles of those specs, and laying out exactly what's happening at each step for people to follow. -- Justin On Mon, 2010-09-27 at 11:35 -0400, Eran Hammer-Lahav wrote: This is a stupid discussion. We have been talking past each other (the working group) for over a year. We are not likely to convince either side that bearer tokens are bad or good idea. All these experts reviewed WRAP in the strict context of their own environment, with existing protocols and other weaknesses. Other and I are reviewing it in the wider context of what is good for the web, and am much less concerned about complexity. IOW, I don’t believe that in this case WRAP made the right choice between developer ease and security. This is also exactly the problem with the current specification. New readers are more likely to assume that what is good for these big companies is also good for them, without making their own threat model analysis. How would they reach any other conclusion when the specification doesn’t offer a complete alternative? We should focus on finding a compromise everyone can live with, since clearly debating the two sides has produced nothing. I think positioning bearer tokens as the primary mechanism, but including a signature alternative in the same specification is a reasonable compromise. Bearer token fans get the spotlight, while those looking for a signature (providing the same protections as 1.0a HMAC-SHA-1) get some algorithm included. We need to find a way to give each side something to live with. EHL From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Monday, September 27, 2010 6:31 AM To: John Panzer; Eran Hammer-Lahav Cc: OAuth WG; Ben Laurie Subject: Re: [OAUTH-WG] Basic signature support in the core specification I'll echo John's comments and remind you that Micrsoft, Yahoo! and Google security experts with plenty of real world experience worked on WRAP which is OAuth bearer tokens. Microsoft, Google, Salesforce, Facebook and others have deployed bearer token OAuth in production after internal security reviews. I don't think that is a personal opinion, that is fact. wrt. another comment you had about security considerations, Brian Eaton did write up a bunch of security considerations for WRAP. On 2010-09-27, at 12:01 AM, John Panzer wrote: On Sun, Sep 26, 2010 at 11:37 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Sunday, September 26, 2010 11:21 PM What I absolutely object to is presenting a specification that to a new reader will read as if bearer tokens are the default way to go. OAuth 2.0 core today reads like a complete protocol and that's my problem. It is a complete protocol for many existing use cases. That's clearly a matter of personal opinion :-) and why we have been arguing about this for over a year. For those use cases where it is not, you can call require signatures and point people to the signature spec, just like the use of bearer tokens points people to the TLS specs. According to Ben Laurie [1] and Ben Adida [2], a simple reference to TLS is a recipe for disaster. Actually in [1], Ben Laurie does not say that a simple reference to TLS is a recipe for disaster. (Go read it.) In fact his first point is that you need a well-define threat model before you can talk sensibly about any of this; I would really like us to do that in this case too. People tend to implement TLS incorrectly on the client side which voids many of
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
+1 on the split. I think it's an elegant approach, and it won't be any harder to follow than a monolithic spec with multiple optional sections. Especially if we put together the right guidance as a gateway to the spec. OAuth 1.0 (and -a) really talk about three different things: how to get a token, how to use a token, and how to sign an HTTP request so that you know who it came from without using full two-way TLS. Much of the confusion that I've seen on What is OAuth surrounding 1.0 came from this conflation of three things. The fact that two-legged OAuth still gets to be called OAuth at all, even when it doesn't touch a token, speaks to this discontinuity, and it remains to me the most shining example of why we do need signatures but that they shouldn't be tied to OAuth tokens. Spec 1 can provide common ways (profiles) to get tokens and provide mechanisms for extending the methods of getting tokens (the grant-type parameter) along with mechanisms for extending what goes with the token (token secrets, for example). Spec 2 can provide ways to use bearer-style OAuth tokens with a PR. This will be a short an simple spec, and mostly concerned with making sure everybody names the parameter the right thing. Spec 3/4 can provide ways to use signed tokens with a PR, through signed HTTP requests (oauth 1.0a, magic signatures) or signed tokens (JWT), or both. These can in turn provide mechanisms for extending the signature algorithms, key management, etc. I've long been in favor of factoring out signing, and I don't see any downsides to this approach right now. -- Justin On Tue, 2010-09-28 at 02:25 -0400, Eran Hammer-Lahav wrote: (Please take a break from the other threads and read this with an open mind. I have tried to make this both informative and balanced.) --- IETF Process For those unfamiliar with the IETF process, we operate using rough consensus. This means most people agree and no one strongly objects. If someone strongly objects, it takes a very unified group to ignore that person, with full documentation of why the group chose to do so. That person can raise the issue again during working group last call, area director review, and IETF last call - each has the potential to trigger another round of discussions with a wider audience. That person can also appeal the working group decision before it is approved as an RFC. The process is managed by the working group chairs. The chairs elect the editor and make consensus calls. So far this working group had only a few consensus calls (breaking the 1.0a RFC into two parts and dropping these in favor of a unified WRAP + 1.0a draft). From my experience and understanding of the process, this working group does not have rough consensus on any of the open items to make consensus calls and close the issues. Simply dismissing the few objections raised will not accomplish finishing the document sooner, but will only add more rounds of debates now and at a later time. One of the problems we have is that we work without a charter. Usually, the charter is the most useful tool chairs have when limiting scope and closing debates. For example, had we fixed the charter last year to explicitly say that we will publish one document with both bearer tokens and signatures, the chairs could have ended this argument by pointing to the charter. Since we have no charter, the chairs have little to offer in terms of ending these disagreements. We never officially agreed what we are here to solve. The reality of this working group is that we need to find a way to make everyone happy. That includes every one of those expressing strong opinions. Any attempt to push people around, dismiss their views, or reject reasonable compromises will just keep the issues open. If this small group cannot reach agreement, the specification will surely fall apart during working group last call, area director review, IETF last call, application area review, security area review, general area review, IANA review, and IESG review. It’s a long process, and at each step, anyone can raise their hand and object. A united working group is the most important tool to end discussions over objections and concerns raised at each step. It also give people the confidence to implement a working group final draft before it is published as an RFC (because it is much less likely to change). --- Open Issues This working group has failed to reach consensus on a long list of items, among them are the inclusion of signatures, signatures format, use of HTTP authentication headers, restrictions on bearer tokens, support for specific profiles, etc. While many of these items faded away, I would not be surprise to see them all come back. The current argument over signatures ignores compromises and agreements reached over the past two years. This working group explicitly rejected WRAP as the replacement for
Re: [OAUTH-WG] Signatures...what are we trying to solve?
I think of the signature issues as falling into two classes... I think they map to your classification as well... * *Signing tokens* is important for interoperability especially looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host. * *Signing messages* is important because it provides a mechanism to ensure that the entity making the API call (and presenting an access token) is really the entity that is allowed to make the API call. Signing messages applies to the re-delegation use cases. I've heard the need for this class of use cases from both the hData (health data) community as well as the user managed access (UMA) community. Signing tokens covers both your second class of tokens as well as another use case that Eran has mentioned as well. Namely, a protected resource server honoring tokens from multiple Authorization Servers. These are the two classes of use cases that I'd like to see solved. Thanks, George On 9/28/10 12:58 AM, David Recordon wrote: If you know me then you'll know that I'm generally one of the last people to talk about Alice and Bob. That said, there are a lot of technical proposals flying across the list with very little shared understanding of the problem(s) we're trying to solve. From what I've seen there are two distinct classes of signature use cases. 1) The first is where the HTTP request parameters must be part of the signature. An example is any OAuth 1.0a style API where you want to make sure that the HTTP POST your server just received isn't masquerading itself as a GET. 2) The second is where the HTTP request is orthogonal. An example is OpenSocial where the server is sending state information to the client such as what user is currently logged in. The main practical example I have of the first use case is what Twitter wants to do with redelegation. In this case TweetDeck can't given TwitPic it's own bearer token, but needs to sign the POST request and pass that signature to TwitPic for it to include in the final API request to Twitter. In terms of signing protected resource requests, I haven't heard anyone bring up specific and detailed needs for this recently. JSON tokens pretty clearly make sense for the second class of signature use cases and it's actually a bit hard to argue why they would be a part of OAuth. Facebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it is 18 lines of PHP. http://developers.facebook.com/docs/authentication/canvas This second class of use case will also be required by OpenID Connect where the server is signing identity information and sending it to the client. I imagine that OpenSocial will also still have it and wish to continue relying on public key algorithms. So a few questions: * Do we want to tackle both of these classes of signatures in OAuth? * Why do you consider the second class part of OAuth versus something completely separate that might happen to include an OAuth access token? * Is the Twitter redelegation use case the right focus for the first class? * Is there an example of an OAuth 2.0 server that can't use bearer tokens for protected resource requests and thus requires signatures? Thanks, --David ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
+1 I think this is a great path forward On 9/28/10 2:25 AM, Eran Hammer-Lahav wrote: (Please take a break from the other threads and read this with an open mind. I have tried to make this both informative and balanced.) --- IETF Process For those unfamiliar with the IETF process, we operate using rough consensus. This means most people agree and no one strongly objects. If someone strongly objects, it takes a very unified group to ignore that person, with full documentation of why the group chose to do so. That person can raise the issue again during working group last call, area director review, and IETF last call - each has the potential to trigger another round of discussions with a wider audience. That person can also appeal the working group decision before it is approved as an RFC. The process is managed by the working group chairs. The chairs elect the editor and make consensus calls. So far this working group had only a few consensus calls (breaking the 1.0a RFC into two parts and dropping these in favor of a unified WRAP + 1.0a draft). From my experience and understanding of the process, this working group does not have rough consensus on any of the open items to make consensus calls and close the issues. Simply dismissing the few objections raised will not accomplish finishing the document sooner, but will only add more rounds of debates now and at a later time. One of the problems we have is that we work without a charter. Usually, the charter is the most useful tool chairs have when limiting scope and closing debates. For example, had we fixed the charter last year to explicitly say that we will publish one document with both bearer tokens and signatures, the chairs could have ended this argument by pointing to the charter. Since we have no charter, the chairs have little to offer in terms of ending these disagreements. We never officially agreed what we are here to solve. The reality of this working group is that we need to find a way to make everyone happy. That includes every one of those expressing strong opinions. Any attempt to push people around, dismiss their views, or reject reasonable compromises will just keep the issues open. If this small group cannot reach agreement, the specification will surely fall apart during working group last call, area director review, IETF last call, application area review, security area review, general area review, IANA review, and IESG review. It's a long process, and at each step, anyone can raise their hand and object. A united working group is the most important tool to end discussions over objections and concerns raised at each step. It also give people the confidence to implement a working group final draft before it is published as an RFC (because it is much less likely to change). --- Open Issues This working group has failed to reach consensus on a long list of items, among them are the inclusion of signatures, signatures format, use of HTTP authentication headers, restrictions on bearer tokens, support for specific profiles, etc. While many of these items faded away, I would not be surprise to see them all come back. The current argument over signatures ignores compromises and agreements reached over the past two years. This working group explicitly rejected WRAP as the replacement for OAuth 1.0 and the whole point of combining 1.0a with WRAP was the inclusion of signatures. We reached another agreement to keep signatures at the Anaheim meeting. The current draft is a version of WRAP alone. There are currently three separate threads going on: 1. OAuth 1.0a style signatures vs. JSON proposals 2. Including a signature mechanism in core 3. Concerns about bearer tokens and HTTPS The first item will not be resolved because we are not going to reach industry consensus over a single signature algorithm (this is a general comment, not specific to these two proposals). The only thing we can do is let those who care about each solution publish their own specification and let the market decide. The second item, while it was part of the very first compromise this working group made (when we combined the two specifications), cannot be resolved because of #1. We can't agree on which signature method to include, and including all is not practical. For these reasons, including a signature algorithm in core is not likely to happen. I have made some proposals but they received instant negative feedback which means we have no consensus. The third item has also been debated and blogged for a long time and is not going to be resolved in consensus. Instead, we will need to find the right language to balance security concerns with the reality that many providers are going to deploy bearer tokens no matter what the IETF says. The OAuth 1.0a RFC was blocked by the IESG until the PLAINTEXT method required HTTPS, and I would expect the same issue to come up with the current
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
Eran- Thanks for writing a great explanation of where we are so far. I agree that it makes sense to logically separate getting a token from using a token, and we should structure it so that there can be extension specs about how to use a token. It also seems clear that we should do some more work to build consensus on signature method. Both great points. As far as the charter: this workgroup has had a focus on building an interoperable, easy-to-use, developer-friendly standard that is actually used. With the goal of market adoption, we should strive to codify those practices that will people will use. Bearer tokens are already widely adopted - Facebook, Twitter, Google, Microsoft, and others are already using this. While I understand that there are some security considerations, on balance, these companies have chosen that it's an acceptable tradeoff. In the interest of interoperability, doesn't it make sense to include the way that many people are going to use it in the spec? Anyway, by defining a default parameter, aren't we already admitting that the spec isn't complete without bearer tokens anyway? On Sep 27, 2010, at 11:25 PM, Eran Hammer-Lahav wrote: (Please take a break from the other threads and read this with an open mind. I have tried to make this both informative and balanced.) --- IETF Process For those unfamiliar with the IETF process, we operate using rough consensus. This means most people agree and no one strongly objects. If someone strongly objects, it takes a very unified group to ignore that person, with full documentation of why the group chose to do so. That person can raise the issue again during working group last call, area director review, and IETF last call - each has the potential to trigger another round of discussions with a wider audience. That person can also appeal the working group decision before it is approved as an RFC. The process is managed by the working group chairs. The chairs elect the editor and make consensus calls. So far this working group had only a few consensus calls (breaking the 1.0a RFC into two parts and dropping these in favor of a unified WRAP + 1.0a draft). From my experience and understanding of the process, this working group does not have rough consensus on any of the open items to make consensus calls and close the issues. Simply dismissing the few objections raised will not accomplish finishing the document sooner, but will only add more rounds of debates now and at a later time. One of the problems we have is that we work without a charter. Usually, the charter is the most useful tool chairs have when limiting scope and closing debates. For example, had we fixed the charter last year to explicitly say that we will publish one document with both bearer tokens and signatures, the chairs could have ended this argument by pointing to the charter. Since we have no charter, the chairs have little to offer in terms of ending these disagreements. We never officially agreed what we are here to solve. The reality of this working group is that we need to find a way to make everyone happy. That includes every one of those expressing strong opinions. Any attempt to push people around, dismiss their views, or reject reasonable compromises will just keep the issues open. If this small group cannot reach agreement, the specification will surely fall apart during working group last call, area director review, IETF last call, application area review, security area review, general area review, IANA review, and IESG review. It’s a long process, and at each step, anyone can raise their hand and object. A united working group is the most important tool to end discussions over objections and concerns raised at each step. It also give people the confidence to implement a working group final draft before it is published as an RFC (because it is much less likely to change). --- Open Issues This working group has failed to reach consensus on a long list of items, among them are the inclusion of signatures, signatures format, use of HTTP authentication headers, restrictions on bearer tokens, support for specific profiles, etc. While many of these items faded away, I would not be surprise to see them all come back. The current argument over signatures ignores compromises and agreements reached over the past two years. This working group explicitly rejected WRAP as the replacement for OAuth 1.0 and the whole point of combining 1.0a with WRAP was the inclusion of signatures. We reached another agreement to keep signatures at the Anaheim meeting. The current draft is a version of WRAP alone. There are currently three separate threads going on: 1. OAuth 1.0a style signatures vs. JSON proposals 2. Including a signature mechanism in core 3. Concerns about bearer tokens and HTTPS The first item will not be resolved because we are not going to reach industry consensus over a single signature algorithm (this is a
Re: [OAUTH-WG] Signatures...what are we trying to solve?
These use cases are not in the draft https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth. Could you write them up? Thanks, Zachary From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher Sent: Tuesday, September 28, 2010 11:39 AM To: OAuth WG Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve? I think of the signature issues as falling into two classes... I think they map to your classification as well... * Signing tokens is important for interoperability especially looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host. * Signing messages is important because it provides a mechanism to ensure that the entity making the API call (and presenting an access token) is really the entity that is allowed to make the API call. Signing messages applies to the re-delegation use cases. I've heard the need for this class of use cases from both the hData (health data) community as well as the user managed access (UMA) community. Signing tokens covers both your second class of tokens as well as another use case that Eran has mentioned as well. Namely, a protected resource server honoring tokens from multiple Authorization Servers. These are the two classes of use cases that I'd like to see solved. Thanks, George On 9/28/10 12:58 AM, David Recordon wrote: If you know me then you'll know that I'm generally one of the last people to talk about Alice and Bob. That said, there are a lot of technical proposals flying across the list with very little shared understanding of the problem(s) we're trying to solve. From what I've seen there are two distinct classes of signature use cases. 1) The first is where the HTTP request parameters must be part of the signature. An example is any OAuth 1.0a style API where you want to make sure that the HTTP POST your server just received isn't masquerading itself as a GET. 2) The second is where the HTTP request is orthogonal. An example is OpenSocial where the server is sending state information to the client such as what user is currently logged in. The main practical example I have of the first use case is what Twitter wants to do with redelegation. In this case TweetDeck can't given TwitPic it's own bearer token, but needs to sign the POST request and pass that signature to TwitPic for it to include in the final API request to Twitter. In terms of signing protected resource requests, I haven't heard anyone bring up specific and detailed needs for this recently. JSON tokens pretty clearly make sense for the second class of signature use cases and it's actually a bit hard to argue why they would be a part of OAuth. Facebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it is 18 lines of PHP. http://developers.facebook.com/docs/authentication/canvas This second class of use case will also be required by OpenID Connect where the server is signing identity information and sending it to the client. I imagine that OpenSocial will also still have it and wish to continue relying on public key algorithms. So a few questions: * Do we want to tackle both of these classes of signatures in OAuth? * Why do you consider the second class part of OAuth versus something completely separate that might happen to include an OAuth access token? * Is the Twitter redelegation use case the right focus for the first class? * Is there an example of an OAuth 2.0 server that can't use bearer tokens for protected resource requests and thus requires signatures? Thanks, --David ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
-Original Message- From: Luke Shepard [mailto:lshep...@facebook.com] Sent: Tuesday, September 28, 2010 9:16 AM As far as the charter: this workgroup has had a focus on building an interoperable, easy-to-use, developer-friendly standard that is actually used. With the goal of market adoption, we should strive to codify those practices that will people will use. Bearer tokens are already widely adopted - Facebook, Twitter, Google, Microsoft, and others are already using this. Sure. I have no disagreement with this. However, while these companies have many resources to make educated decisions about their security architecture, this is not the case for most startups and smaller companies. The challenge is always finding the right balance between interop, security, and usability. We don't want to scare people away from using the protocol, but we do want to make sure they really understand the security tradeoff proposed. I am willing to bet less than 10% of those who read the 1.0a specification read the security consideration section. While I understand that there are some security considerations, on balance, these companies have chosen that it's an acceptable tradeoff. And that's clearly their decision to make. I disagree with these tradeoffs and have expressed that. I am not trying to make them change their mind. But while you are focused solely on building a product today, I am focused on the future. I cannot put my name on a specification that I strongly believe will promote a practice I am opposed to, even if it is widely deployed today. By offering an equally accessible alternative, I hope some will make a different choice. In the interest of interoperability, doesn't it make sense to include the way that many people are going to use it in the spec? Yes, but nothing is lost by breaking it into two documents. We can keep debating this until we reach consensus (which is likely never), or we can 'agree to disagree' by putting everything we agree on in one document, and everything we don't in another. By employing a modular approach, you get what you need, and I get the ability to offer an alternative - both presented equally. It is this equality that I care most about. Anyway, by defining a default parameter, aren't we already admitting that the spec isn't complete without bearer tokens anyway? The specification describing how to obtain a token is clearly incomplete without another document telling you how to use the token you obtained. I would rather not have a default value at all, and require the parameter present with every token response. I am willing to define a default scheme value to keep this proposal at zero implementation impact. From a protocol architecture perspective, it would be much better not to have a default value. This is another compromise, and if it becomes an argument for not splitting the documents, I will drop my support for a default value. At the end, I doubt most Facebook, Google, Microsoft, or Salesforce developers will bother to ever read the RFC. They will read the API documentation provided by each company. Some library developers will read it, but I hope they will read all the parts to provide a comprehensive support for bearer tokens, signed tokens, signed requests, common assertions, etc. I think splitting the current spec into two documents is a reasonable compromise with some useful side benefits. This is a carefully balanced proposal which I hope will get us moving forward quickly. The time for trying to come up with a plan for a single document has passed. We are not going to agree on what such a single document includes. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Signatures...what are we trying to solve?
* Is there an example of an OAuth 2.0 server that can't use bearer tokens for protected resource requests and thus requires signatures? The use case I see for signatures that isn't solved (as well) by tokens is 3 way integrations where it is useful to manage a secret as a way to manage the business relationship. I have also seen a lot of cases where the 3rd party doesn't want to go SSL (I'm not gonna try to justify this, it's just how things have worked that I've seen). From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David Recordon Sent: Monday, September 27, 2010 9:58 PM To: OAuth WG Subject: [OAUTH-WG] Signatures...what are we trying to solve? If you know me then you'll know that I'm generally one of the last people to talk about Alice and Bob. That said, there are a lot of technical proposals flying across the list with very little shared understanding of the problem(s) we're trying to solve. From what I've seen there are two distinct classes of signature use cases. 1) The first is where the HTTP request parameters must be part of the signature. An example is any OAuth 1.0a style API where you want to make sure that the HTTP POST your server just received isn't masquerading itself as a GET. 2) The second is where the HTTP request is orthogonal. An example is OpenSocial where the server is sending state information to the client such as what user is currently logged in. The main practical example I have of the first use case is what Twitter wants to do with redelegation. In this case TweetDeck can't given TwitPic it's own bearer token, but needs to sign the POST request and pass that signature to TwitPic for it to include in the final API request to Twitter. In terms of signing protected resource requests, I haven't heard anyone bring up specific and detailed needs for this recently. JSON tokens pretty clearly make sense for the second class of signature use cases and it's actually a bit hard to argue why they would be a part of OAuth. Facebook shipped this a bit over a month ago for canvas applications. We include a `signed_request` parameter which is signature.base64url(JSON). Parsing it is 18 lines of PHP. http://developers.facebook.com/docs/authentication/canvas This second class of use case will also be required by OpenID Connect where the server is signing identity information and sending it to the client. I imagine that OpenSocial will also still have it and wish to continue relying on public key algorithms. So a few questions: * Do we want to tackle both of these classes of signatures in OAuth? * Why do you consider the second class part of OAuth versus something completely separate that might happen to include an OAuth access token? * Is the Twitter redelegation use case the right focus for the first class? * Is there an example of an OAuth 2.0 server that can't use bearer tokens for protected resource requests and thus requires signatures? Thanks, --David ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
+1 seems like a pragmatic compromise On Tue, Sep 28, 2010 at 12:44 PM, Marius Scurtescu mscurte...@google.com wrote: On Tue, Sep 28, 2010 at 9:05 AM, George Fletcher gffle...@aol.com wrote: +1 I think this is a great path forward +1 Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
+1. -- John Panzer / Google jpan...@google.com / abstractioneer.org http://www.abstractioneer.org/ / @jpanzer On Mon, Sep 27, 2010 at 11:25 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: (Please take a break from the other threads and read this with an open mind. I have tried to make this both informative and balanced.) --- IETF Process For those unfamiliar with the IETF process, we operate using rough consensus. This means most people agree and no one strongly objects. If someone strongly objects, it takes a very unified group to ignore that person, with full documentation of why the group chose to do so. That person can raise the issue again during working group last call, area director review, and IETF last call - each has the potential to trigger another round of discussions with a wider audience. That person can also appeal the working group decision before it is approved as an RFC. The process is managed by the working group chairs. The chairs elect the editor and make consensus calls. So far this working group had only a few consensus calls (breaking the 1.0a RFC into two parts and dropping these in favor of a unified WRAP + 1.0a draft). From my experience and understanding of the process, this working group does not have rough consensus on any of the open items to make consensus calls and close the issues. Simply dismissing the few objections raised will not accomplish finishing the document sooner, but will only add more rounds of debates now and at a later time. One of the problems we have is that we work without a charter. Usually, the charter is the most useful tool chairs have when limiting scope and closing debates. For example, had we fixed the charter last year to explicitly say that we will publish one document with both bearer tokens and signatures, the chairs could have ended this argument by pointing to the charter. Since we have no charter, the chairs have little to offer in terms of ending these disagreements. We never officially agreed what we are here to solve. The reality of this working group is that we need to find a way to make everyone happy. That includes every one of those expressing strong opinions. Any attempt to push people around, dismiss their views, or reject reasonable compromises will just keep the issues open. If this small group cannot reach agreement, the specification will surely fall apart during working group last call, area director review, IETF last call, application area review, security area review, general area review, IANA review, and IESG review. It’s a long process, and at each step, anyone can raise their hand and object. A united working group is the most important tool to end discussions over objections and concerns raised at each step. It also give people the confidence to implement a working group final draft before it is published as an RFC (because it is much less likely to change). --- Open Issues This working group has failed to reach consensus on a long list of items, among them are the inclusion of signatures, signatures format, use of HTTP authentication headers, restrictions on bearer tokens, support for specific profiles, etc. While many of these items faded away, I would not be surprise to see them all come back. The current argument over signatures ignores compromises and agreements reached over the past two years. This working group explicitly rejected WRAP as the replacement for OAuth 1.0 and the whole point of combining 1.0a with WRAP was the inclusion of signatures. We reached another agreement to keep signatures at the Anaheim meeting. The current draft is a version of WRAP alone. There are currently three separate threads going on: 1. OAuth 1.0a style signatures vs. JSON proposals 2. Including a signature mechanism in core 3. Concerns about bearer tokens and HTTPS The first item will not be resolved because we are not going to reach industry consensus over a single signature algorithm (this is a general comment, not specific to these two proposals). The only thing we can do is let those who care about each solution publish their own specification and let the market decide. The second item, while it was part of the very first compromise this working group made (when we combined the two specifications), cannot be resolved because of #1. We can’t agree on which signature method to include, and including all is not practical. For these reasons, including a signature algorithm in core is not likely to happen. I have made some proposals but they received instant negative feedback which means we have no consensus. The third item has also been debated and blogged for a long time and is not going to be resolved in consensus. Instead, we will need to find the right language to balance security concerns with the reality that many providers are going to deploy bearer tokens no matter what the IETF says. The OAuth 1.0a RFC was
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
+1 Eran, thanks for framing this up... On Sep 28, 2010, at 12:14 PM, Brian Campbell wrote: +1 seems like a pragmatic compromise On Tue, Sep 28, 2010 at 12:44 PM, Marius Scurtescu mscurte...@google.com wrote: On Tue, Sep 28, 2010 at 9:05 AM, George Fletcher gffle...@aol.com wrote: +1 I think this is a great path forward +1 Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
On 9/28/10 12:25 AM, Eran Hammer-Lahav wrote: (Please take a break from the other threads and read this with an open mind. I have tried to make this both informative and balanced.) --- IETF Process For those unfamiliar with the IETF process, we operate using rough consensus. This means most people agree and no one strongly objects. If someone strongly objects, it takes a very unified group to ignore that person, with full documentation of why the group chose to do so. That person can raise the issue again during working group last call, area director review, and IETF last call - each has the potential to trigger another round of discussions with a wider audience. That person can also appeal the working group decision before it is approved as an RFC. To clarify, rough consensus does not mean unanimity and it does not mean one vocal person can launch their own personal DoS against the WG. The chairs (and if necessary the sponsoring AD) do have tools at their disposal for declaring consensus. That said, I think your proposal is a reasonable compromise for how to move this WG forward. Peter -- Peter Saint-Andre https://stpeter.im/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
+1 The proposal makes sense. I particularly like the side effect that the use of access tokens is no longer bound to HTTP. Hui-Lan Lu From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, September 28, 2010 2:26 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Looking for a compromise on signatures and other open issues (Please take a break from the other threads and read this with an open mind. I have tried to make this both informative and balanced.) --- IETF Process For those unfamiliar with the IETF process, we operate using rough consensus. This means most people agree and no one strongly objects. If someone strongly objects, it takes a very unified group to ignore that person, with full documentation of why the group chose to do so. That person can raise the issue again during working group last call, area director review, and IETF last call - each has the potential to trigger another round of discussions with a wider audience. That person can also appeal the working group decision before it is approved as an RFC. The process is managed by the working group chairs. The chairs elect the editor and make consensus calls. So far this working group had only a few consensus calls (breaking the 1.0a RFC into two parts and dropping these in favor of a unified WRAP + 1.0a draft). From my experience and understanding of the process, this working group does not have rough consensus on any of the open items to make consensus calls and close the issues. Simply dismissing the few objections raised will not accomplish finishing the document sooner, but will only add more rounds of debates now and at a later time. One of the problems we have is that we work without a charter. Usually, the charter is the most useful tool chairs have when limiting scope and closing debates. For example, had we fixed the charter last year to explicitly say that we will publish one document with both bearer tokens and signatures, the chairs could have ended this argument by pointing to the charter. Since we have no charter, the chairs have little to offer in terms of ending these disagreements. We never officially agreed what we are here to solve. The reality of this working group is that we need to find a way to make everyone happy. That includes every one of those expressing strong opinions. Any attempt to push people around, dismiss their views, or reject reasonable compromises will just keep the issues open. If this small group cannot reach agreement, the specification will surely fall apart during working group last call, area director review, IETF last call, application area review, security area review, general area review, IANA review, and IESG review. It's a long process, and at each step, anyone can raise their hand and object. A united working group is the most important tool to end discussions over objections and concerns raised at each step. It also give people the confidence to implement a working group final draft before it is published as an RFC (because it is much less likely to change). --- Open Issues This working group has failed to reach consensus on a long list of items, among them are the inclusion of signatures, signatures format, use of HTTP authentication headers, restrictions on bearer tokens, support for specific profiles, etc. While many of these items faded away, I would not be surprise to see them all come back. The current argument over signatures ignores compromises and agreements reached over the past two years. This working group explicitly rejected WRAP as the replacement for OAuth 1.0 and the whole point of combining 1.0a with WRAP was the inclusion of signatures. We reached another agreement to keep signatures at the Anaheim meeting. The current draft is a version of WRAP alone. There are currently three separate threads going on: 1. OAuth 1.0a style signatures vs. JSON proposals 2. Including a signature mechanism in core 3. Concerns about bearer tokens and HTTPS The first item will not be resolved because we are not going to reach industry consensus over a single signature algorithm (this is a general comment, not specific to these two proposals). The only thing we can do is let those who care about each solution publish their own specification and let the market decide. The second item, while it was part of the very first compromise this working group made (when we combined the two specifications), cannot be resolved because of #1. We can't agree on which signature method to include, and including all is not practical. For these reasons, including a signature algorithm in core is not likely to happen. I have made some proposals but they received instant negative feedback which means we have no consensus. The third item has also been debated and blogged for a long time and is not going to be resolved in consensus. Instead, we will need to
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
+1 The proposal makes sense. I particularly like the good side effect that the use of access tokens is no longer bound to HTTP. Hui-Lan Lu From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, September 28, 2010 2:26 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Looking for a compromise on signatures and other open issues (Please take a break from the other threads and read this with an open mind. I have tried to make this both informative and balanced.) --- IETF Process For those unfamiliar with the IETF process, we operate using rough consensus. This means most people agree and no one strongly objects. If someone strongly objects, it takes a very unified group to ignore that person, with full documentation of why the group chose to do so. That person can raise the issue again during working group last call, area director review, and IETF last call - each has the potential to trigger another round of discussions with a wider audience. That person can also appeal the working group decision before it is approved as an RFC. The process is managed by the working group chairs. The chairs elect the editor and make consensus calls. So far this working group had only a few consensus calls (breaking the 1.0a RFC into two parts and dropping these in favor of a unified WRAP + 1.0a draft). From my experience and understanding of the process, this working group does not have rough consensus on any of the open items to make consensus calls and close the issues. Simply dismissing the few objections raised will not accomplish finishing the document sooner, but will only add more rounds of debates now and at a later time. One of the problems we have is that we work without a charter. Usually, the charter is the most useful tool chairs have when limiting scope and closing debates. For example, had we fixed the charter last year to explicitly say that we will publish one document with both bearer tokens and signatures, the chairs could have ended this argument by pointing to the charter. Since we have no charter, the chairs have little to offer in terms of ending these disagreements. We never officially agreed what we are here to solve. The reality of this working group is that we need to find a way to make everyone happy. That includes every one of those expressing strong opinions. Any attempt to push people around, dismiss their views, or reject reasonable compromises will just keep the issues open. If this small group cannot reach agreement, the specification will surely fall apart during working group last call, area director review, IETF last call, application area review, security area review, general area review, IANA review, and IESG review. It's a long process, and at each step, anyone can raise their hand and object. A united working group is the most important tool to end discussions over objections and concerns raised at each step. It also give people the confidence to implement a working group final draft before it is published as an RFC (because it is much less likely to change). --- Open Issues This working group has failed to reach consensus on a long list of items, among them are the inclusion of signatures, signatures format, use of HTTP authentication headers, restrictions on bearer tokens, support for specific profiles, etc. While many of these items faded away, I would not be surprise to see them all come back. The current argument over signatures ignores compromises and agreements reached over the past two years. This working group explicitly rejected WRAP as the replacement for OAuth 1.0 and the whole point of combining 1.0a with WRAP was the inclusion of signatures. We reached another agreement to keep signatures at the Anaheim meeting. The current draft is a version of WRAP alone. There are currently three separate threads going on: 1. OAuth 1.0a style signatures vs. JSON proposals 2. Including a signature mechanism in core 3. Concerns about bearer tokens and HTTPS The first item will not be resolved because we are not going to reach industry consensus over a single signature algorithm (this is a general comment, not specific to these two proposals). The only thing we can do is let those who care about each solution publish their own specification and let the market decide. The second item, while it was part of the very first compromise this working group made (when we combined the two specifications), cannot be resolved because of #1. We can't agree on which signature method to include, and including all is not practical. For these reasons, including a signature algorithm in core is not likely to happen. I have made some proposals but they received instant negative feedback which means we have no consensus. The third item has also been debated and blogged for a long time and is not going to be resolved in consensus. Instead, we will need
Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
-Original Message- From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Tuesday, September 28, 2010 5:09 PM I am mildly concerned that breaking the spec into multiple parts makes it harder for the spec reader to understand what is going on. Where does a complete example of getting and using a token? Imagine how confusing HTTP would be if the request and response were in separate specs. You mean like break the HTTP specification into, say, 7 parts? Maybe something like this: 1: URIs, Connections, and Message Parsing 2: Message Semantics 3: Message Payload and Content Negotiation 4: Conditional Requests 5: Range Requests and Partial Responses 6: Caching 7: Authentication This is exactly what the original HTTP authors are doing these days [1]. You should have probably chose another example to make your point :-). Joking aside, I don't buy this argument for two reasons. First, most developer are not going to read the actual specification - they will read API documentations, books, and tutorials. Very few people actually read RFC 2616 in whole (most just use it as a reference for status codes). Second, you are exaggerating the complexity of following a link to another part. Would it be better to have everything in one document? Sure! But is it worth delaying this work by another year or so? That's the point of this compromise. It gives everyone the technical details they care about, treats competing views equally, at the small cost of having to read one more document (but same number of pages) if you only care about bearer tokens. That's the compromise. I am confident that I can write easy to follow prose that will explain that this specification shows how to obtain a token, while other specifications show how to use it (and discuss the specific properties of different token types). I believe my detailed proposal addresses all the points raised in your feedback. EHL [1] http://tools.ietf.org/wg/httpbis/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
