[OAUTH-WG] Revised Charter
Hi all, Now that the Easter holiday is over, please review the following revised OAuth charter and provide feedback by May 5th (one week from today). Thanks! Description of Working Group The Open Web Authentication (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account. OAuth consists of * a mechanism for a user to authorize issuance of credentials that a third party can use to access resources on the user's behalf and * a mechanism for using the issued credentials to authenticate HTTP requests. In April 2010 the OAuth 1.0 specifcation, documenting pre-IETF work, was published as an informational document (RFC 5849). The working group has since been developing OAuth 2.0, a standards-track version that will reflect IETF consensus. Version 2.0 will consider the implementation experience with version 1.0, and will * improve the terminology used, * consider broader use cases, * embody good security practices, * improve interoperability, and * provide guidelines for extensibility. The working group will develop authentication schemes for peers/servers taking part in OAuth (accessing protected resources). This includes * an HMAC-based authentication mechanism [to the extent that the OAuth wg produces specifications that could be used more generally for HTTP authentication, the WG will work with the security and applications area directors to ensure that this work gets appropriate review, e.g. via additional last calls in other relevant working groups such as httpbis], * a specification for access protected by Transport Layer Security (bearer tokens), * an extension to OAuth 2.0 to allow access tokens to be requested when a client is in possession of a SAML assertion. A separate informational description will be produced to provide additional security analysis for audiences beyond the community protocol implementers. Milestones will be added for the later items after the near-term work has been completed. Goals and Milestones May 2011Submit 'HTTP Authentication: MAC Authentication' as a working group item May 2011Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Jul 2011Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard Jul 2011Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Aug 2011Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Oct 2011Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0' to the IESG for consideration as a Proposed Standard Nov 2011Prepare re-chartering ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Code Swap Attack
From my chair-seat, Barry's interpretation matches mine. Having carefully reviewed Eran's revised text vis-a-vis the proposal from Anthony et al., it seems like the concerns are addressed without forcing the use of any specific mechanism to maintain state, which is commensurate with the approach to the problem in the HTTP world. Reviewing the history of the state parameter, and thinking about how it will be used within a functioning system, I'm inclined to agree with Eran's most recent comments. Thus, the challenge for me is whether or not there is a way to introduce a required CSRF parameter that meets the security requirements, can be implemented seamlessly in libraries, and is reasonably scalable in its default (library-driven) form (my intuition says there isn't). b. On 15 August 2011 17:35, Eran Hammer-Lahav wrote: > To demonstrate why making state required as proposed isn’t very helpful, > here is an incomplete list of other requirements needed to make an effective > CSRF: > > > > * State value must not be empty (a common bug in many implementations using > simple value comparison). > > > > * ‘Non-guessable’ isn’t sufficient as most developers will simply use a hash > of the session cookie, with or without salt which isn’t sufficient. We use > “cannot be generated, modified, or guessed to produce valid values” > elsewhere in the document, but this is much easier to get right for access > tokens and refresh tokens than CSRF tokens which are often just some > algorithm on top of the session cookie. > > > > * State CSRF value should be short-lived or based on a short-lived session > cookie to prevent the use of a leaked state value in multiple attacks on the > same user session once the leak is no longer viable. > > > > In addition, this is not what “state” was originally intended for. If the > working group decides to mandate a CSRF parameter, it should probably be a > new parameter with a more appropriate name (e.g. ‘csrf’). By forcing clients > to use “state” for this purpose, developers will need to use dynamic queries > for other state information which further reduces the security of the > protocol (as the draft recommends not using dynamic callback query > components). Encoding both CSRF tokens and other state information can be > non-intuitive or complicated for some developers/platforms. > > > > EHL > > > > > > > > > > From: Eran Hammer-Lahav > Sent: Friday, August 12, 2011 2:53 PM > To: Anthony Nadalin; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > This is really just a flavor of CSRF attacks. I have no objections to better > documenting it (though I feel the current text is already sufficient), but > we can't realistically expect to identify and close every possible > browser-based attack. A new one is invented every other week. > > > > The problem with this text is that developers who do no understand CSRF > attacks are not likely to implement it correctly with this information. > Those who understand it do not need the extra verbiage which is more > confusing than helpful. > > > > As for the new requirements, they are insufficient to actually accomplish > what the authors propose without additional requirements on state local > storage and verification to complete the flow. Also, the proposed text needs > clarifications as noted below. > > > > > > From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 > To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack > > > > > > > > Recommended Changes to draft-ietf-oauth-v2 > > > > In section 4, request options (e.g. 4.1.1) featuring "state" should change > from: > > > > state > > OPTIONAL. An opaque value used by the client to maintain state between the > request and callback. The authorization server includes this value when > redirecting the user-agent back to the client. > > > > to: > > > > state > > REQUIRED. An opaque value used by the client to maintain state between the > request and callback. The authorization server includes this value when > redirecting the user-agent back to the client. The encoded value SHOULD > enable the client application to determine the user-context that was active > at the time of the request (see section 10.12). The value MUST NOT be > guessable or predictable, and MUST be kept confidential. > > > > > > Making the parameter required without making its usage required (I.e. "value > SHOULD enable") accomplishes nothing. Also, what does "MUST be kept > confidential" mean? Confidential from what? Why specify an "encoded value"? > > > > > > Section 10.12 Cross-Site Request Forgery > > > > Change to: > > > > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP > requests are transmitted from the user-agent of an end-user the server > trusts or has authenticated. CSRF attacks enable the attacker to intermix > the attacker's security context with that of the resource owner resulting in > a compromise of either the resource server or of
Re: [OAUTH-WG] MAC: Age in nonce
+1. This is good. On 19 November 2011 16:41, Eran Hammer-Lahav wrote: > We had a long discussion about what to use for the numerical component of > the nonce string. I would like to suggest we use: > > > > nonce > > REQUIRED. A unique string generated by the client to allow the > > server to verify that a request has never been made before and > > helps prevent replay attacks when requests are made over an > > insecure channel. The nonce value MUST be unique across all > > requests with the same MAC key identifier. > > > > The nonce value MUST consist of an age, a colon character > > (%x25), and a unique string (typically random). The age > > portion MUST be a monotonically increasing, but not necessarily > > unique, positive integer value. The change in the age value > > between requests MUST reflect the number of seconds elapsed. > > For example, the age can be a client timestamp expressed as > > seconds since 01-01-1970 or since the credentials were issued > > to the client. The value MUST NOT include leading zeros (e.g. > > "000273156"). For example: "273156:di3hvdf8" > > > > To avoid the need to retain an infinite number of nonce values > > for future checks, the server MAY choose to restrict the time > > period after which a request with an old age is rejected. If > > such a restriction is enforced, the server SHOULD allow for a > > sufficiently large window to accommodate network delays. The > > server SHOULD use the first age value received from the client > > to establish a method for comparing the server time with that > > of the client. In addition, the server SHOULD accommodate small > > negative changes in age values caused by differences between > > the multiple clocks of a distributed client configuration > > utilizing more than one device. > > > > This text keeps the age as a seconds count but uses the first request to > establish a clock sync on the server side instead of mandating one way to > calculate it. > > > > Feedback? > > > > EHL > > > > > > ___ > 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] Mandatory-to-implement token type
On 2 December 2011 03:20, Barry Leiba wrote: > Stephen is thinking that code will be reused. Perhaps there'll be a > limited number of coded toolkits, and their code will be used to > implement various authorization servers, etc. That's the way a lot of > Internet code is done today. In that case, Stephen posits, if we tell > the toolkit writers that they MUST implement X, then at least when X > is being used, implementations based on the different toolkits can > always interoperate. Lacking that directive, a toolkit that only > implements X will be unable to interoperate with a toolkit that only > implements Y. My $0.02 (tl;dr: I agree with Barry): Libraries are the point of code re-use for OAuth at the moment. If two libraries (e.g., "Ruby OAuth" and "Java OAuth") implement all the necessary bits of OAuth, then people using those libraries can expect (or hope for) interop. We cannot force compliance, but we can mandate it. If a service provider chooses to allow only a subset of OAuth's functionality, and a general-purpose tool (i.e., NOT a library, though perhaps written using a library) doesn't support that subset, then obviously the implementations are not interoperable. However, more likely than not, tools are designed to be used against specific service providers OR other standards (which would in either case mandate the way(s) in which to use OAuth). SO, having Mandatory to Implement schemes in the general sense is pointless. BUT, having BOTH Bearer and MAC be Mandatory to Implement for general-purpose libraries IS useful, and will help interop (assuming library authors bother to follow the spec). b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Mandatory-to-implement token type
On 4 December 2011 02:26, Mike Jones wrote: > I strongly object to a mandatory-to-implement clause for the MAC scheme. > They are unnecessary and market forces have shown that implementers do not > want or need this kind of an authentication scheme. I'd say that Twitter, Flickr, Dropbox and dozens of other sites that have shipped OAuth 1.0a (MAC) in production and for billions of requests per day is a pretty strong market force. People (especially politically incentivised standards wonks) arguing on a mailing list isn't a strong market force, and there are far fewer successful APIs that use Bearer tokens. Which isn't to say that they won't, just to say that what you want and what's used in the wild are very different things. Or, citation needed. b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Mandatory-to-implement token type
On 11 December 2011 11:30, Leif Johansson wrote: > > 5 dec 2011 kl. 00:34 skrev Blaine Cook : > > Oauth 1.0a mac and 2.0 mac are not the same thing. Yours is an argument for > backwards compat I think. The syntax is different / better, the spec is cleaner, but they specify exactly the same thing. I couldn't care less about all this at this point, but I do take issue with the claim that the MAC approach in general (as typified by OAuth 1.0a and the MAC Token draft as-is) doesn't have adoption. b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 and Access Control Lists (ACL)
On 18 December 2011 17:22, Doug Tangren wrote: > > On Sun, Dec 18, 2011 at 12:05 PM, Melvin Carvalho > wrote: >> >> Is this kind of flow possibly with OAuth 2.0, and if so whose >> responsibility is it to maintain the list of agents than can access >> the resource? > > The scope parameter fulfills this role. It would be up to the service to > document the scope for clients, the auth server to ask the user if they > wished allow the client this extra scope of access, and the resource server > to interpret the scope for the particular request. It's not necessary to use the scope parameter; you'd probably want some private API that allows an authenticated client to say something like: "User x is also allowed to access this resource", and when User X's client obtains an access token, they'll be able to access the resource in question. The ACL in any event is the responsibility of the service provider, as the service provider is the only entity able to enforce access control. b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth WG Re-Chartering
On 14 March 2012 20:21, Hannes Tschofenig wrote: > So, here is a proposal: > > [Editor's Note: New work for the group. 5 items maximum! ] > > Aug. 2012 Submit 'Token Revocation' to the IESG for consideration as a > Proposed Standard > Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a > Proposed Standard > Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth > 2.0' to the IESG for consideration > Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG > for consideration as a Proposed Standard > Sep. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an > Informational RFC This looks great to me. I have serious concerns about feature-creep, and think that the OAuth WG should strongly limit its purview to these issues. In general, I think it prudent for this working group in particular to consider standardisation of work only under the following criteria: 1. Proposals must have a direct relationship to the mechanism of OAuth (and not, specifically, bound to an application-level protocol). 2. Proposals must have significant adoption in both enterprise and startup environments. 3. Any proposal must be driven based on a consideration of the different approaches, as adopted in the wild, and strive to be a better synthesis of those approaches, not a means to an end. These are the constraints with which I started the OAuth project, and they're more relevant than ever. I'd hate to see OAuth fail in the end because of a WS-*-like death by standards-pile-on. b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth WG Re-Chartering
On 15 March 2012 17:31, Zeltsan, Zachary (Zachary) wrote: > ... Considering OpenID Connect as a motivating use case for OAuth, SWD is > the one spec that would then be missing for this OAuth use case. I worry that bringing OpenID Connect into OAuth (rather than building upon OAuth) will have detrimental effects for both efforts. OAuth is successful in part because we chose not to push OAuth-like functionality into the OpenID umbrella (which at the time was focused on shipping OpenID 2.0). It seems prudent to learn from the experience of WS-*, where everything was combined into one huge ball of standards-wax. The result was both impenetrable and not fit for purpose due to the many interdependencies (both social and technical) involved. Composition has served the IETF and the internet well, and nothing prevents the OpenID standards from being created in the context of a new working group, or from within the OpenID foundation. Indeed, it's been working quite well, and projects like the Account Chooser are showing great promise and focusing on the important things (UX) rather than specifications-for-specification's sake. b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
On 12 April 2012 17:51, Mike Jones wrote: > Thanks for asking these questions Hannes. I'll first provide a brief > feature comparison of Simple Web Discovery and WebFinger and then answer > your questions. > > FEATURE COMPARISON > > RESULT GRANULARITY AND PRIVACY CHARACTERISTICS: SWD returns the resource > location(s) for a specific resource for a specific principal. WebFinger > returns all resources for the principal. The example at > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2"Retrieving > a Person's Contact Information" is telling. The WebFinger > usage model seems to be "I'll get everything about you and then fish > through it to decide what to do with it." The protocol assumption that all > WebFinger information must be public is also built into the protocol where > the CORS response header "Access-Control-Allow-Origin: *" is mandated, per > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7. > The privacy characteristics of these approaches are very different. (It's > these very same privacy characteristics that led sysadmins to nearly > ubiquitously disabling the fingerd service!) Particularly for the OAuth > use cases, narrow, scoped, and potentially permissioned responses seem > preferable. > This is absolutely false. SWD provides no privacy whatsoever. SWD makes it somewhat harder to crawl large numbers of profiles, but it does not incorporate any real security, and any attempt to suggest that it does is misleading and deceptive. Webfinger, like any good HTTP service, is designed to allow access control using appropriate means. That access control should not be *bound* to the protocol, in the same way that HTTP does not have any REQUIRED access control mechanisms, since doing so would severely restrict future usage of a core protocol. FUD has no place in a discussion of the technical and social merits of a protocol. For what it's worth, my intent with webfinger *from day one, nearly four years ago*, has been to provide permissioned profile data *using EXISTING* (or new, where appropriate or necessary, based on *running code and deployment EXPERIENCE*) access control mechanisms for profile data. The idea that there is ONE view of the data is patently false. For example, depending on who is requesting my profile data, I might return different contact telephone numbers, and this behaviour is completely feasible using webfinger. > DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY: WebFinger is > built on a "document model", where a single document is returned that > contains multiple resources for a principal. SWD is built on an "API > model", where the location(s) of a particular resource for a principal are > returned. The problem with the document model is that different parties or > services may be authoritative for different resources for a given > principal, and yet all need the rights to edit the resulting document. > This hurts deployability, because document edits then need to be > coordinated among parties that may have different rights and > responsibilities, and may have negative security implications as well. > (Just because I can change your avatar doesn't mean that I should be able > to change your mail server.) > WS-* was built on an API model, and that worked out very well. APIs and documents on the web are the same thing; how you represent them behind the scenes is up to you, and that's been a core principle of the web since shortly after its inception. Suggesting otherwise profoundly misunderstands how implementation of web services happens. SWD says nothing of how to update profile data, so the security concerns here are a total red herring. > REDIRECT FUNCTIONALITY AND DEPLOYABILTY: SWD includes the ability to > redirect some or all SWD requests to another location (possibly depending > upon the specific resource and principal parameters). Deployers hosting > numerous sites for others told the SWD authors that this functionality is > critical for deployability, as it means that the SWD server for a domain > can live in a location outside the domain. WebFinger is lacking this > functionality. Given that OAuth is likely to be used in hosted > environments, this functionality seems pretty important. > Umm, I'm not even sure what to say to this. host-meta is a static file that points to a profile server (generally expected to be a dynamic "API" server) that can be hosted on any domain. The fact that you're suggesting that this core piece of webfinger functionality is *missing* seriously undermines my belief that you're acting in good faith, Mike. > NUMBER OF ROUND TRIPS: WebFinger discoveries for user information > normally require both a host-meta query to retrieve the template and then a > second query to retrieve the user's information. This functionality is > achieved in a single SWD query. > ... at the cost of greater client complexity. A webfinger lookup may be implemented with the foll
Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
On 13 April 2012 12:18, Mike Jones wrote: > Hi Blaine. I must admit, I’m pretty surprised by the tone of your > reply. I’ll say up front that I have absolutely no problem with anyone > disagreeing with me on a technical or tactical basis. If you think I’m > wrong, have at it. > > ** ** > > But I am pretty shocked that you would decide to impugn my motives. We’ve > only met twice and both times I thought we had really useful and productive > discussions about how to move digital identity on the Web forward – > something I believe that we’re both passionate about. You don’t really > know me, though, which is apparent from your remarks below. I believe that > those who have worked with me for years would vouch that I am a forthright > and evenhanded standards participant who listens to all points of view, > tries to build a consensus that works, and produce quality results. > > > I thought about your note overnight and whether I should reply at all. > I’m fine with give and take, but I believe that I need to say that if you > read what you wrote below, I think you’ll agree that the tone you used was > counter-productive and an apology is in order. > I'm sorry for any offensive comments or tone on my part. I was really taken aback by your comments, because we have had those conversations about Webfinger/SWD, and your technical commentary seemed to me to attempt to intentionally undermine webfinger in ways that I couldn't fathom, given the things we've previously discussed in person. I look forward to moving ahead with future discussions on SWD/Webfinger (frankly, SWD is a better name. ;-) ) in the apps area, and hope that my irate tone hasn't caused any permanent rift. I think we both agree that this work is incredibly important for the future of the web, and I'm hopeful that we can build the best mechanism to provide that future. Best, b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
That's a tricky question - maybe one google can help answer? There are a bunch of projects using webfinger, including status.net, ostatus in general, diaspora, unhosted, freedombox(?), and I'm sure others, but I have no idea how that translates into actual users or profiles. Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't been much movement, I think due to the chicken and egg nature of adoption around decentralized tools. b. On Apr 17, 2012 11:13 AM, "Tim Bray" wrote: > What is the deployment status of these two specs? Is either deployed > much at all? -T > > On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy > wrote: > >> -Original Message- > >> From: apps-discuss-boun...@ietf.org [mailto: > apps-discuss-boun...@ietf.org] On Behalf Of Stephen Farrell > >> Sent: Friday, April 13, 2012 9:23 AM > >> To: oauth@ietf.org WG > >> Cc: Apps Discuss > >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web > Discovery (SWD) > >> > >> So Hannes and Derek and I have been discussing this with the Apps ADs > >> and Apps-area WG chairs. I've also read the docs now, and after all > >> that we've decided that this topic (what to do with swd and webfinger) > >> is best handled in the apps area and not in the oauth WG. > >> > >> The logic for that is that 1) the two proposals are doing the same > >> thing and we don't want two different standards for that, b) this is > >> not an oauth-specific thing nor is it a general security thing, and c) > >> there is clearly already interest in the topic in the apps area so its > >> reasonable for the oauth wg to use that when its ready. > >> > >> The appsawg chairs and apps ADs are ok with the work being done there. > >> > >> So:- > >> > >> - I've asked the oauth chairs to take doing work on swd > >> out of the proposed new charter > >> - It may be that you want to add something saying that > >> oauth will use the results of work in the applications > >> area on a web discovery protocol as a basis for doing > >> the dynamic client registration work here > >> - Discussion of webfinger and swd should move over to > >> the apps-discuss list > >> - Note: this is not picking one or the other approach, > >> the plan is that the apps area will do any selection > >> needed and figure out the best starting point for a > >> standards-track RFC on web discovery and we'll use their > >> fine work for doing more with oauth. > > > > Thank you Stephen, I think. :-) > > > > So the discussion on apps-discuss now should be focused on which of the > two should be the basis for forward progress. I've placed both documents > in "Call for Adoption" state in the datatracker for appsawg. > > > > Let the games begin. > > > > -MSK > > ___ > > apps-discuss mailing list > > apps-disc...@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > ___ > 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] [apps-discuss] R: draft-jones-appsawg-webfinger-04
I disagree that the current spec is a good starting point - the issues I've raised have been ignored, and the spec is now much more complicated from both sides of the implementation fence. On May 7, 2012 3:17 PM, "Paul E. Jones" wrote: > Walter, > > I'm not sure what the full set of issues will be, but I only have a couple > of small edits queued for -05 at present (one being "template" should be > "href" in the example at the end of 4.2 that you pointed out to me > privately). We've already worked through a number of issues to get to this > point, so there may not be a lot of changes needed. I'll not dismiss the > possibility that there are editorial issues, but I hope we've resolved most > of the technical details. > > We probably still need to have the discussion of keeping CORS and what > additions are needed to the security section. We've made a few changes > there already, but I'm not sure if it still fully addresses some of the > privacy concerns. > > Paul > > On 5/7/2012 5:37 AM, Goix Laurent Walter wrote: > > I also support this draft as a way forward for the discussion that I > think captures the essence of both philosophies. > > ** ** > > If such basis is agreed what are the major pending issues? > > ** ** > > Regards > > Laurent-walter > > ** ** > > *Da:* apps-discuss-boun...@ietf.org > [mailto:apps-discuss-boun...@ietf.org] > *Per conto di *Gonzalo Salgueiro (gsalguei) > *Inviato:* venerdì 4 maggio 2012 21.50 > *A:* Murray S. Kucherawy > *Cc:* oauth@ietf.org; apps-disc...@ietf.org > *Oggetto:* Re: [apps-discuss] draft-jones-appsawg-webfinger-04 > > ** ** > > I support this doc being adopted as starting point for WG discussion. > > Regards, > > ** ** > > Gonzalo > > ** ** > > > On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" > wrote: > > The above-named draft has been offered as the recommended path forward > in terms of converging on a single document to advance through appsawg. > The conversation I saw this week in that regard has seemed mostly positive. > > > > > Please review it, or at least the diff, and indicate your support or > objection on apps-disc...@ietf.org to adopting this one as the common > path forward. We would like to make a decision about which one to begin > advancing in the next week or two. > > > > Have a good weekend! > > > > -MSK, APPSAWG co-chair > > > > ___ > apps-discuss mailing list > apps-disc...@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > ___ > 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] [apps-discuss] draft-jones-appsawg-webfinger-04
On 8 May 2012 16:55, Hannes Tschofenig wrote: > The discussions around XML vs. JSON are unfortunately also hiding the real > important discussion, namely privacy. > > We are actually building, without further thinking about it, a mechanism that > offers worse privacy properties compared to what we have in other protocols > today. > > See this in terms of the interaction between a relying party and an identity > provider then other IETF protocols today (e.g., AAA) does not require the > relying party to see the username part of the identifier. In fact AAA offers > various mechanisms to hide the username component to the relying party since > it is really only needed by the identity provider. > > So, I would encourage the group to think about how to accomplish equivalent > functionality without unnecessarily revealing identifiers to parties that are > not supposed to get them. Webfinger isn't about authentication. It is *explicitly* about discovering information about an entity (usually a person) when you (the relying party) *already have* their identifier. Again: There is NO privacy leak in exposing the identifier to the RP, because they already know it. Again: There is NO privacy leak in exposing the identifier to the SP, because they control it. Even in the context of authentication, I'm surprised you're saying this because I've repeatedly claimed that the *major failing* with OpenID *.* is that the relying party isn't given knowledge of *who* is trying to authenticate in the first place. It's a cryptographic property that looks lovely on paper, but is a damaging folly when translated to something that end users are expected to interact with. > I also think it is useful to think about the bigger picture,namely the > integration with other protocols (such as OAuth). This will in most cases be > needed when you actually fetch the data that is behind the discovered URIs. > Assuming that all information is public anyway is not realistic and protocol > design has to work with the difficult assumptions (not with the simplest). Agreed, the actual information conveyed by Webfinger will normally be private. *However*, as discussed on this list, on the OAuth list, and in many other places, the mechanism(s) for authentication and authorisation to access the relevant Webfinger profiles is best dealt with by allowing any valid HTTP mechanisms. Specific protocols that rely upon webfinger should define their own authentication requirements, where sensible. > Hence, I heavily object to use this document as a starting point. I have many concerns with this document, too, as mentioned earlier. > I may also be the case that WebFinger is not the right tool for something > like OAuth (and for discovery of protected resources altogether) since we do > not want to design a solution that on one hand allows us not to reveal any > user identifiers to the relying party (the client in OAuth) based on the > current design and then completely destroy these properties when we add the > discovery mechanisms in front of it. No-one is forcing all OAuth services to rely upon webfinger discovery. OpenID Connect needs something like this, because users (and their RPs in turn) need to know their identifier in order to be able to sign in. Some RPs that interact with OAuth-enabled services (e.g., cloud document services) will benefit from webfinger. Others won't, especially where the RP shouldn't or can't know who the user is, but should have access to a service. FWIW, I think you're blowing the privacy concerns way out of proportion, especially in the context of a world where many actively hostile actors can identify users by analysing router traffic that they obtain from back-doors in switches manufactured by Ericsson. ;-) b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Signatures, Why?
One of the things that's been a primary focus of both today's WG call and last week's call is what are the specific use cases for signatures? - Why are signatures needed? - What do signatures need to protect? Let's try to outline the use cases! Please reply here, so that we have a good idea of what they are as we move towards the Anaheim WG. b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Virtually Attending
Hi all, just a heads up that events have conspired such that I won't be at the meeting in person, but will be participating via webex. Peter will be present, and with his forthcoming appointment as Apps Area Director, will be imbued with the moderating powers of ten ordinary Chairs (as if he wasn't already). cheers, b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Next Steps
Hi all, Hannes and I have discussed the results of the WG meeting, and while there was a lot of good discussion that happened, it seems like the next step for the WG is to buckle down and produce a stable draft that incorporates all the various proposals, in particular WRAP and OAuth 1.0a. David has done an excellent job with his draft, and I'd like to see us follow through on that work quickly and effectively to offer the various organizations who are looking to ship interoperable solutions something to base their work on. To that end, we'd like to see Eran take up the editing work over the next week. That work should be premised on re-incorporating the features from WRAP that were removed in David's great start at a unified spec. Dick's contributions have been invaluable towards reconciling the gap between HMAC-based approaches and expiring bearer token approaches, and we'd like to see that work be properly credited and evaluated along with all of the other aspects of OAuth 1.0a and WRAP. Our hope is that soon, certainly well before the next OAuth WG meeting (virtual or otherwise), we'll have a new RFC-style document that satisfies the needs of everyone in the community. Blaine and Hannes. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures
My take on this is that MUSTs MAY be ignored. ;-) To echo John's concerns here, the worst-case scenario is that client libraries implement "no SSL present" as a gentle reminder warning with a flag (possibly the default) to disable those HTTPS warnings. Clients that behave in that way should be flagged as non-compliant and publicly humiliated. If we just write SHOULD for HTTPS/secure channel support, then those clients are acting "properly." If WRAP is aiming to just be a replacement for Cookie auth, then why don't we just add a redirection profile for issuing cookies? They work now, refreshing them is built-in, etc, etc. Instead, what we're trying to do is build something better, more secure, and more aligned with the sorts of behaviours we see and want to encourage on the web. b. On 6 April 2010 11:54, John Panzer wrote: > My $.02: SHOULD is okay, as long as all clients MUST support HTTPS. E.g., > SHOULD for service providers, MUST support for clients. > Otherwise, you will end up with clients that don't support https or don't do > it properly. (E.g., don't bother to check certificates.) Which hurts > security for service providers that do want SSL. > > On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt > wrote: >> >> +1 for the standard should recommand HTTPS or comparable means of >> transport protection but not require it. >> >> This requirement does not result in any benefit for the specification by >> itself (e.g. simplification). Therefore, the decision to use HTTPS or any >> other means should be up to the service providers based on its security >> considerations. >> >> One of the biggest differences between OAuth2 and WRAP is that OAuth2 >> requires that Protected Resources be accessed using HTTPS if no signature is >> being used. Bullet Point #2 in Section 1.2 says: >> >> 4. Don't allow bearer tokens without either SSL and/or signatures. >> While some providers may offer this ability, they should be out >> of spec for doing so though technically it won't break the flows. >> >> While I personally think that requiring SSL is a fantastic idea, and it’s >> very hard for me to argue against it, however >> >> One of the goals for WRAP was to define a standard AuthZ interface for >> APIs which matched what we currently have on the Web. WRAP protected APIs >> are intended to be a replacement for screen scraping. >> >> On the web, almost all websites implement Cookie Auth. Specifically, when >> you log into a website, the browser is issued a bearer token, called a >> Cookie, and the browser is able to access Protected Resources by using the >> Cookie as the credential. >> >> The WRAP access token is intended to be a direct replacement for the HTTP >> Cookie. A client should be able to present its bearer token (a WRAP Access >> Token or an HTTP Cookie) without having to sign the request. >> >> While I certainly think that requiring SSL would be a huge improvement in >> internet security, HTTP does not require SSL, and since WRAP was intended to >> be a replacement for HTTP Cookie Auth, then OAuth2 should also not require >> HTTPS. >> >> Yes, dropping the SSL requirement isn’t optimal, but again the intent with >> WRAP was to replace HTTP Cookie auth, and it should be up to the service >> provider to require HTTPS when applicable. >> >> Allen >> >> ___ >> 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 > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Reminder, 4/19 deadline for -00 WG draft feedback
This is a reminder that feedback that you'd like to see incorporated into the -00 working group draft is due by 4/19 (Monday). Please submit comments as a separate message to this list. Thanks! b. (see recent posts to the list and http://www.ietf.org/mail-archive/web/oauth/current/msg01957.html in particular for current status) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Call for Consensus (Deadline: April 22)
This is a call for consensus on accepting Eran's latest OAuth draft, draft-hammer-oauth2 [1] as a working group item. Assuming no objections by end-of-day Tuesday, April 22nd, this draft will be promoted to an active working group document on Wednesday, April 23rd. b. [1] http://datatracker.ietf.org/doc/draft-hammer-oauth2/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for Consensus (Deadline: April 27)
On 23 April 2010 17:01, Peter Saint-Andre wrote: > On 4/23/10 8:05 AM, Prateek Mishra wrote: >> Do you mean April 29 (Thu) and April 30th (Fri)? > > Clearly yes. lol, neither. I think I managed to look at a 2009 calendar somehow, and travel has left me completely unaware as to the current date. To clarify: Hannes and I will promote Eran's draft to a working group document on Wednesday the *28th* barring any concerns. The deadline is Tuesday, the 27th. Sorry for any confusion! b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Call for Issues
Hannes and I are currently working on preparing an agenda for next week's meeting. In addition to the two issues Eran has open for comments on the list, we would like to solicit open issues from the community. Thanks to the incredible efforts that Eran and everyone else who has contributed recently, the scope and complexity of the issues has decreased substantially. As such, we'd like to incorporate the use of the working group issue tracker[1] to provide a simplified way to track progress and ensure that we're not losing things as we go. WHAT'S NEEDED FROM YOU: If you'd like to discuss an issue or idea at the upcoming meeting, you must add your issue to the issue tracker before 16:00 PST, SUNDAY, MAY 16 (that's midnight Sunday for those in Europe). You can create new tickets by going to [2]; if you haven't used (or can't remember using) the IETF issue tracker before, the easiest way to get started is to visit [3], set a password, and then visit [2]. This will give everyone the opportunity to coalesce, sub-divide, and prioritise issues before the meeting next week. If you do not raise your issue before Sunday, we cannot guarantee that there will be time to discuss it at the meeting. thanks very much from the chairs, Blaine & Hannes [1] http://trac.tools.ietf.org/wg/oauth/trac/report/1 [2] http://trac.tools.ietf.org/wg/oauth/trac/newticket [3] http://trac.tools.ietf.org/newlogin ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme
On 28 May 2010 02:21, Brian Eaton wrote:
> OAuth 1.0 was unusual in that it required that the server match a hash
> of the URL, rather than the real URL. It's an extra layer of
> indirection and complexity. It doesn't improve security.
To be more precise, OAuth 1.0 required that the server match a
normalised form of the URL. You're absolutely correct that it doesn't
improve security [over matching the URL], but it *is* more secure than
either not proving that the token bearer provided the URL in the first
place or having the client and server match potentially different
versions of the URL.
This is a problem of leaky abstractions: if HTTP was used in a way
such that the client unequivocally asserted "This: {x} is the
unabridged HTTP URL that I am requesting", and such that {x} was
presented untouched to the service handling the request, then we
wouldn't have to worry about normalisation.
As it stands, getting access to the raw request URL is relatively
difficult in many environments that handle HTTP requests, and even
more difficult to obtain from HTTP client libraries, since the actual
request URI is often constructed in a private method at the last
moment before a request is actually made.
Which is all to say that it is indeed complex, but much of that
complexity is a result of HTTP libraries trying to hide complexity
from users. I'd echo Roy's assertion that as library support improves,
approaches to URL normalisation will become hidden behind the same
layers of abstraction as constructing query strings and request URIs
are today.
b.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?
I agree with Dick that the scope should remain out of scope for OAuth. ;-) Having a shared parameter here gives the illusion of interoperability, but because there's no common understanding of permissible scopes, there's no way to guarantee that any given client-server pair could expect to produce predictable outcomes. Furthermore, limiting the format of the scope prematurely means that we give up on a whole set of possibilities before we've even had a chance to see what those possibilities are. For example, YQL might want to allow a scope to be defined like "SELECT * FROM flickr" or something similar. Maybe scope is implicit in assertions, or even explicit. Scope might be tied to the degree to which the requesting and/or granting parties are trusted by the service provider. If there were a compelling story about how scope is supposed to realistically achieve greater interoperability, it might be worthwhile for us to consider it. In the meantime, though, I think it just represents the same featuritis drive that got us an under-specified (and more harmful than helpful) version parameter in OAuth 1.0. b. On 25 June 2010 08:59, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Dick pointed me to the Facebook API on how scope is used. > The main page is here: > http://developers.facebook.com/docs/authentication/ > > It describes the basic functionality and also lists an example: > > " > https://graph.facebook.com/oauth/authorize? > client_id=...& > redirect_uri=http://www.example.com/callback&; > scope=user_photos,user_videos,publish_stream > " > > The values of the scope parameter are then explained here: > http://developers.facebook.com/docs/authentication/permissions > > Example: user_photos ... Provides access to the photos the user has uploaded > > I think it provides a good example that the scope values are not opaque. > Opaque (in this context) means that only the entity creating it needs to > understand it and nobody else. Here the client needs to understand and set > them. > > However, one could argue that the scope values are already bound to the > specific entity the client requests to obtain the assertion from. In this > specific case it would be "https://graph.facebook.com";. > > To respond to the statement Dick made about having standardized values later > there would still be the need to decide about the structure of the values > now. One possibility is to just add a prefix for standardized values that are > not allowed to be used in other cases, such as "std:". > > Ciao > Hannes > > >> -Original Message- >> From: ext William Mills [mailto:wmi...@yahoo-inc.com] >> Sent: Thursday, June 24, 2010 8:15 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas >> Rosenstock; Dick Hardt >> Cc: OAuth WG >> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> >> I'm in favor of having a spaces separated list of tokens. >> The only case I can think of where the client needs to handle >> the scope as anything other than opaque is when it is >> accessing multiple services. To reduce the numebr of login >> events the client will have to poll all the endpoints it >> wants to access and get all the scopes advertized by them and >> submit them all, and once it has them it needs to submit all >> of them in it's auth request, so we need something that's >> easy for the client to put together. >> >> >> -bill >> >> > -Original Message- >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] >> > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> > Sent: Thursday, June 24, 2010 3:58 AM >> > To: ext Lukas Rosenstock; Dick Hardt >> > Cc: OAuth WG >> > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> > >> > The question is whether one would ever want to have a >> > standardized semantic for the scope parameter. >> > If the answer to that question is "no" then it does not >> > matter what the format is. It can well be a list of >> > space-delimited strings (as it is currently defined). >> > >> > An evironment specific semantic works well in cases where >> > entity X sets the value and later it receives the value >> > again. Only entity X needs to understand what it means. >> > >> > In some environments the use case is slightly different, >> > namely entity X and entity Y are from the same organization >> > and agree on the semantic. Usage of OAuth within an >> > enterprise might be such a case. >> > >> > Now, the usage of the scope parameter is, however, a bit >> > different in the spec. Section 4, for example, describes how >> > a client obtains an access token. How does the client know >> > what scope parameters to set and what the semantic is? >> > >> > Ciao >> > Hannes >> > >> > > -Original Message- >> > > From: ext Lukas Rosenstock [mailto:l...@lukasrosenstock.net] >> > > Sent: Thursday, June 24, 2010 10:49 AM >> > > To: Dick Hardt >> > > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >> > > Subject: Re: [OAUTH-WG] Scope :: Was: Ex
Re: [OAUTH-WG] POLL: Are you going to Maastricht?
A, BUT I will be unable to attend Monday-Wednesday. I'll be around Thursday / Friday to work on issues and so forth if others will be there, too. b. On 8 July 2010 17:43, Justin Richer wrote: > D > > On Thu, 2010-07-08 at 12:29 -0400, David Recordon wrote: >> I'm honestly trying to decide myself and a few other people are in >> similar situations. Thus a poll: >> A) Yes, I'm going to be in Maastricht >> B) Maybe, depends on the number of OAuth WG members going >> C) Maybe, depends on some other reason >> D) No >> >> >> If you're missing context, in a few weeks it is the IETF meeting >> in Maastricht (http://www.ietf.org/meeting/78/). The OAuth WG has a >> meeting scheduled all afternoon Tuesday the 27th. >> >> >> 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] user-agent flow needs a rewrite
I don't claim to fully grok what the current state of the various proposals are regarding the user agent flow, but fundamentally, shouldn't we be aiming to replicate what Twitter and Facebook are already doing? We've already moved towards JSON as a standard format, why not go all the way and mandate either JSONP or CORS support, and explicitly build around a Javascript-centric model (since that's really what we're talking about, and that's what is deployed today). b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] "shared symmetric secret"
+1 on "like a password", or something similar-and-meaningful because that's exactly how it's being used here. Pre-shared key, shared secret, etc, would be fine. Keep in mind that authentication *will be done* using the bearer token, and the bearer token alone. An OAuth token is unlike capabilities in that capabilities tend to be bound to addressable data – in most OAuth deployments, the data addressing is separate from the token. b. On 13 July 2010 19:46, Richer, Justin P. wrote: >>> I would be very unhappy if we equated access tokens with passwords. >>> >>> I agree with Dirk that "capability" is a more expressive phrase than either >>> "shared secret" or "password". > >> Expressive to you and people well-versed in security theory. It means >> nothing to a casual reader. The token definition includes the term, but in >> this section, it is referring to how an access token is used, and it is used >> just like a password. > > Definitely agree with Eran here. The term "capability" doesn't mean much to > me in this circumstance, but "like a password" tells me exactly what I, as an > implementer, can expect. > > -- Justin > ___ > 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] "shared symmetric secret"
On 13 July 2010 20:31, John Kemp wrote: > Where is that specified? Is that required for all implementations? It's not specified - I was referring to your earlier comments: > In the "bearer token" case (and even over SSL unless client certs are used), > the > token clearly SHOULD NOT be used as a password. Rather, authentication should > be performed by some other mechanism, unrelated to the token itself (such as > an > HMAC, or via client-certificate SSL/TLS, or even via an actual > username/password) > I would be very unhappy if we equated access tokens with passwords. The token is never used as the authentication mechanism (i.e., the mechanism to authenticate the user), except in schemes where it explicitly makes sense (e.g., UMA as I understand it, Twitter's OAuth Echo, etc). So there's no concern about that. What I was trying to say, and I'm just re-iterating Eran's comments here, is that once issued [in the context of a request made by an authenticated user that grants authorization to the OAuth client], the token will be used de-facto as a password, passphrase, shared secret, or whatever we want to call it. By calling it a "capability", we don't signal to implementors what the security implications are, and what they can do to avoid disappointment. > A capability, basically, is a reference to an object and the permission to > use it, bound together. Possession of the capability is enough to authorize > the use of the reference. Bearer tokens follow roughly that model. They are > about authorization and MAY be used alone for authentication, but may also be > used with (specified, or not, in OAuth) other mechanisms for authentication. > At least I hope that is the model (not to *require* servers to authenticate > using the bearer token alone even if *some* implementations do that)? It's unclear what you mean is being authenticated by the server – do you mean the user, or the client, or something else? This question is persistent and points to exactly the kind of confusion I think Eran is correct to try to avoid by simply calling the token password-like. If we use language that clearly indicates to developers that "with the clear-text token, requests can be made [modulo reduced permissions] as though they were made by someone in possession of the user's username and password. Don't leak it, and treat it as though it were a password", then we avoid having to explain (embarrassingly) that the "capability" actually meant something like "password". b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header
On 15 July 2010 15:59, Justin Richer wrote: > +1 on OAuth2 header, and I also want to see oauth2_token in URI and form > parameter methods. > > 1.0 clients will talk to systems that support both oauth2 and oauth1 > simultaneously. Most likely on the same PR endpoints as well. Since the > protocols are not backwards compatible, they should be able to coexist. I tend to agree with Eran here – 1.0 clients talking to systems that support both OAuth 2 and OAuth 1 will notice no difference. The server will have to switch protocol handling, but can do so on the presence of OAuth 1 or OAuth 2-specific parameters. Clients using OAuth 1.0 shouldn't have to do anything, and shouldn't notice any change. This absolutely makes things a tiny bit more complicated for service providers that have already deployed OAuth 1 services and wish to move to OAuth 2, but frankly if the provider can't figure it out, they have larger problems (unless someone can provide a really compelling reason why switching in this way is actually really hard, I just can't buy it). OAuth is dead, long live OAuth. Right? I mean, you don't move the White House to another address every time you get a new president... b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[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. Please submit your comments by Wednesday, October 20th. - The OAuth Working Group Chairs ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for Consensus on Document Split
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. On 20 October 2010 22:56, Eran Hammer-Lahav wrote: > 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 > >> -Original Message- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Marius Scurtescu >> Sent: Wednesday, October 20, 2010 11:55 AM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Call for Consensus on Document Split >> >> +1 >> >> >> On Thu, Oct 14, 2010 at 12:06 AM, Mike Jones >> 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. >> > >> > -- Mike >> > >> > -Original Message- >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> > Of Blaine Cook >> > Sent: Wednesday, October 13, 2010 5:32 PM >> > To: oauth@ietf.org >> > 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. >> > >> > Please submit your comments by Wednesday, October 20th. >> > >> > - The OAuth Working Group Chairs >> ___ >> 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] Fwd: New Version Notification for draft-campbell-oauth-saml-01
Accepted into the tracker. Thanks, Brian! b. On 4 January 2011 08:26, Brian Campbell wrote: > Thanks Peter. I did update the draft and submit it with a > draft-ietf-oauth- prefix. The I-D submission summary page for it is at > https://datatracker.ietf.org/idst/status.cgi?submission_id=28905 > > On Tue, Jan 4, 2011 at 9:08 AM, Peter Saint-Andre wrote: >> >> >> Agreed. >> >> I'll poke the chairs about accepting this as a WG item. :) >> >> Peter >> >> On 12/14/10 6:26 PM, Eran Hammer-Lahav wrote: >>> Prepare a new draft if needed and submit it with draft-ietf-oauth- >>> prefix. One of the chairs will need to approve it and it will be >>> published. I think we have wide consensus for this and this was >>> already proposed a long time ago with no objections. >>> >>> EHL >>> -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Tuesday, December 14, 2010 10:18 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell- oauth-saml-01 I don't have any objection to it and think it's probably cleaner. Previously I'd informally asked that the SAML profile be considered a WG item and I don't think there was any objection. What needs to be done to make that happen? If you/we take this approach, what else will you need from me? On Tue, Dec 14, 2010 at 9:23 AM, Eran Hammer-Lahav wrote: > Torsten made a good argument that now that we combined assertions > and extensions into a single mechanism, it does not make sense to make the 'assertion' parameter required, and that some extensions will be confusing with such a parameter name. In addition, the recent document split demoted this specification from 'core' to 'framework' which is more friendly to extensions and companion specifications. > > I would suggest we drop the assertion parameter from the spec, > but add a directly reference to the SAML assertion specification and give an example showing the parameter. This will remove the normative language (which really doesn't belong there - something I've long maintained), but will keep the SAML assertion option on equal ground (directly demonstrated in the spec). After all, you can't implement assertions just by reading the framework spec, you still need the SAML work. > > This will require moving the SAML into a WG item (not a must but > best) which I am supportive of and would like to see happen quickly (in a few days). > > Thoughts? > > EHL > >> -Original Message- From: Brian Campbell >> [mailto:bcampb...@pingidentity.com] Sent: Tuesday, December 14, >> 2010 8:11 AM To: Torsten Lodderstedt Cc: Eran Hammer-Lahav; >> oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification >> for draft-campbell- oauth-saml-01 >> >> Future revisions of this SAML draft will build off whatever >> assertion/extension mechanism is provided by the core framework >> spec. However, some compelling reasons were previously given >> for keeping the 'assertion' (one thread on the topic: >> http://www.ietf.org/mail-archive/web/oauth/current/msg04401.html) >> >> >> parameter in core. Has the thinking on that changed? >> >> On Tue, Dec 14, 2010 at 9:05 AM, Torsten Lodderstedt >> wrote: >>> +1 >>> >>> >>> >>> Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav >> : >>> I think the 'assertion' parameter should be moved into this draft and >> defined there. This will also facilitate its proper definition >> and status (required, singular, etc.). EHL > >> >> > ___ > 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] Authorization code security issue (reframed)
DO NOT REPLY TO THIS EMAIL. To Eran's point, before reaching the end of this thread after limited access to email over the weekend, I was going to shut this thread down anyways. I'm not going to issue a call for consensus on this issue, because I don't believe anyone on the list (except for a small handful of active participants) have read even a fraction of the thread. Furthermore, I'm sure that we understand this threat, and we will ensure that it is properly documented in the Security Considerations. If you are reading this, have not had your voice heard on this matter, and think that this issue is unrepresented in the Security Considerations, please email the chairs directly. b. nb: The OAuth working group's job is to ship OAuth 2.0; while this is includes ensuring a secure protocol, "secure" does not equal "impenetrable". If you believe that cookies and security in HTTP is flawed, please go talk to the HTTP working group and lobby for a MUST of TLS over all HTTP connections. I also urge you to consider the implications of Comodogate – $100 certs ain't what they used to be. On 5 April 2011 06:59, Eran Hammer-Lahav wrote: > Blaine, Hannes, > > This thread has gone as far as it can. We need to shut it down and move this > item to the chairs (and potentially the AD) to resolve, given that this is > not a technical issue, but a political/procedural one. I'm asking the chairs > to make a decision about this, given that the working group is unable to > reach a conclusion. > > Rant inline below... > > EHL > > >> -Original Message- >> From: Francisco Corella [mailto:fcore...@pomcor.com] >> Sent: Monday, April 04, 2011 5:46 PM > >> If the IETF endorsed a protocol such that a compliant implementation allows >> user impersonation and unauthorized access to protected resource, then the >> IETF would be endorsing lack of security. How is that inaccurate? > > Because there is no such thing as an IETF endorsement, and a publication of > an RFC only means that the community has reviewed a document and it represent > as full picture as possible (at that time). There is nothing about an IETF > standard that requires it to always pick security over usability, *as long > as* the security issues are well documented, explained, and given the proper > context and warnings. > > Documenting a security issue and recommending a solution is well within IETF > practice. The point of the security consideration section is to make sure > those implementing the standard understand the security issues involved. No > IETF RFC claims to be 100% secure and that any implementation of it can be > 'trusted'. The IETF should *promote* best security practices, as long as they > are practical. > >> The statement is helpful from the point of view of the users who would be >> the victims of the attacks. You seem to be concerned about companies and >> developers but not about users. > > That's crap. The user has no way of gaging anything with regard to the client > or server implementation. It cannot tell if the server has implemented > anything correctly. The user will never even know OAuth exists. Since when > does a standard protect users? There is no enforcement. No IETF police. I am > not even sure the IETF organization can say anything publically about any > particular implementation without opening itself to litigation. > > Users vote with their feet. How many people stopped using webmail services > once they learned about the danger of FireSheep? Practically none. Our job is > to produce technical documents that improve interoperability and abide by the > best security practices possible. Our only audience are the people > implementing the standard. The only question is, will an average developer > reading the document understand the issue and do as much as possible to > address it? > > I'm in the business of building consumer web products. Who do you think are > my customers? We are all here to serve the needs of the end user. But we also > live in the real world where the web is insecure and we have to work with > what we've got. Your position is that it is better to make a stand and force > almost every consumer web company to violate the specification (since you > can't force them to abide by it). My position is that more people will pay > attention to the issue if we explain it and not give them an excuse to ignore > other security related MUSTs (once you ignore the first, the 2nd, 3rd, 10th > come easy). > > If we make this a MUST, we know Facebook is going to ignore it because they > have no other options at this point in time. They are not going to write > 'Almost OAuth 2.0 compliant' on their site. They are not going to even > mention OAuth to their users. But on their developer site they will say they > support OAuth 2.0. Then you will come and write a long blog post about how > they are not really OAuth 2.0 compliant. Great. Now what? 600 million people > will stop usin
Re: [OAUTH-WG] [oauth] OAuth 1.0 PLAINTEXT without SSL/TLS
2010/1/9 John Kemp : > On Jan 8, 2010, at 9:15 PM, Eran Hammer-Lahav wrote: > > What is the actual reasoning behind this change? I don't understand why we > would suddenly now decide to make some whole class of implementations > non-conforming, even if there were only few deployments? Eran did ask if anyone was using OAuth PLAINTEXT without SSL; that said, I don't think that it matters if anyone is using PLAINTEXT with SSL; the spec should outline the basis for interop, and implementations that want to be interoperable and secure MUST check to see that SSL is being used for PLAINTEXT (especially server implementations). Implementations are always free (as in free country) to have special flags that disable the security checks and put their OAuth implementation into non-spec-compliant mode. The same sort of principle applies to TLS client implementations; the certificate chain MUST be checked as per the specification, but many clients allow developers just issue warnings or provide flags to turn off the warnings that the certificate chain checks are not being performed. Even though silenced warnings that your TLS connections are insecure is bad, it's better than the authors of TLS libraries not having to consider those warnings at all. b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Allowing Secrets in the Clear Over Insecure Channels
OAuth WRAP is very similar to cookies as deployed by major vendors. Google has just switched to HTTPS-by-default for all GMail sessions[1], and my understanding (per [2]) is that access to authenticated sessions (i.e., full GMail or Google Docs access versus just displaying "b...@gmail.com" on the page) is always negotiated with a secure cookie. Thus, Google has made decisions internally to secure the equivalent of both the Refresh and the Bearer token, short-lived assurances aside. We're also entering an age where we have enough computing power to *factor* RSA-1024 in non-infinite-time; handheld devices that are realistically expected to use these protocols have sufficient computing power and battery life to encrypt HTTP requests and decrypt the responses (my phone already does this for all Twitter and email requests; yours probably does, too). As such, I can't see how *not* requiring SSL for unsigned requests could pass muster at an IETF security review. [1] http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html [2] http://googleonlinesecurity.blogspot.com/2009/06/https-security-for-web-applications.html 2010/1/14 John Kemp : > > On Jan 14, 2010, at 1:05 AM, Eran Hammer-Lahav wrote: > > [...] >> >> QUESTIONS: Are there any valid (such that will pass IETF security review >> scrutiny) reasons for allowing unsigned requests to be sent in the clear >> over an insecure channel? Are there use cases for this (regardless of their >> security properties)? > > I am still wavering on this. > > I think that using a bearer token with short lifetime and one-time use > semantics (for example) is probably sufficient security for many use-cases. > And using TLS/SSL (or even just signing and verifying a signed request) in > all cases may provide too much performance overhead for some of those cases. > > In other words, I think that it's not only channel security we need to > consider, but a combination of other measures that would, in some cases, > obviate the need for TLS. > > Regards, > > - johnk > > ___ > 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] Request Signing vs. API Signing vs. Message Signing
2010/1/14 Eran Hammer-Lahav : > QUESTION: Do you prefer: > > A. Directly processing the HTTP request into a base string for signing > (draft-hammer-oauth style). > B. Treating the request as an API call with form-encoded parameters (OAuth > 1.0 style). > C. Converting the request into a normalized message and signing that (Eaton > style). For protocol independence of presenting a token + signed message, (C). I wonder if John Panzer's recent proposal for Salmon [1] could be adapted to use (C) elegantly? I think Salmon/PSHB is an interesting use-case for delegated authorization and subsequent authentication, and as such might be a good place to think about approaches like Brian's. b. [1] http://www.abstractioneer.org/2010/01/magic-signatures-for-salmon.html ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Request Signing vs. API Signing vs. Message Signing
2010/1/14 Blaine Cook :
> 2010/1/14 Eran Hammer-Lahav :
>> QUESTION: Do you prefer:
>>
>> A. Directly processing the HTTP request into a base string for signing
>> (draft-hammer-oauth style).
>> B. Treating the request as an API call with form-encoded parameters (OAuth
>> 1.0 style).
>> C. Converting the request into a normalized message and signing that (Eaton
>> style).
>
> For protocol independence of presenting a token + signed message, (C).
> I wonder if John Panzer's recent proposal for Salmon [1] could be
> adapted to use (C) elegantly? I think Salmon/PSHB is an interesting
> use-case for delegated authorization and subsequent authentication,
> and as such might be a good place to think about approaches like
> Brian's.
On second thought (and after reading Eran's Question #2) I'd like to
clarify this a bit; I like that Brian's proposal makes it flexible to
determine what is to be signed. Including the data twice in the
request is silly; perhaps an approach like Brian's, but with the
"message" part replaced with pointers-to-the-message-parts.
e.g.,
instead of envelope:
{ "name": "source.example.com",
"algorithm": "RSA-SHA256",
"timestamp": 1260253850,
"nonce": "0437f743b5809" }
and message:
{ "url": "http://source.example.com/x/y/z"; }
just include the message-parts in the envelope:
{ "name": "source.example.com",
"algorithm": "RSA-SHA256",
"timestamp": 1260253850,
"nonce": "0437f743b5809",
"message": [ "url" ] }
See my reply to Eran's Question #2 for reasoning.
b.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Include Normalized Request with Raw Request
2010/1/14 Eran Hammer-Lahav : > QUESTIONS: How do people feel about this? What are some other advantaged and > disadvantages of this approach? The disadvantages you outlined massively outweigh the advantages. I've had a persistent search for OAuth on Twitter for some time now, and anecdotally, people are "getting" it more, or the libraries are getting better. In that sense, I echo Dirk's sentiment here. The signature in OAuth 1.0+ and in draft-hammer-http-token-auth is designed to break if someone implements something insecurely. The goal of these mechanisms is not to make it easy for people to authenticate insecurely. It's to make it as easy as possible (but no easier) to ensure secure authentication. b. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposed agenda for second interim meeting
I've started a wiki page here:
http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthFeatureMatrix
to pull in the features people think are important, and give us both
some way of collecting that data over time and expressing what's
present or missing from each protocol & proposal. Despite being called
FeatureMatrix, please treat it as a Use Case Matrix.
If people don't want to go in and edit the wiki table (I don't blame
you) please send your use cases to me (rom...@gmail.com) and I will
fill them out on the wiki for you. If you have blog posts or links to
pre-existing use cases or features, please include those as they will
help clarify the features.
b.
ps. the wiki won't let me put in a bookmarklet to make the text entry
not suck (i.e., use a fixed-width font), so here's one in case you do
decide to edit the wiki:
javascript:document.getElementById('text').style.fontFamily='courier'
On 3 February 2010 17:59, Eran Hammer-Lahav wrote:
> I read the minutes.
>
> I don't need to be on the call to present my views on how to proceed. That's
> not how the IETF operates. I have been expressing my views for the past year,
> right here on the list. I didn't see any consensus call from the chairs about
> taking this approach (instead of others).
>
> I also noticed the lack of follow up since the call with any kind of
> discussion on use cases.
>
> I have asked the chairs to provide a place to discuss technical issues and
> that is what this second call is about. Unless the chairs decide to change it.
>
> EHL
>
>> -Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Wednesday, February 03, 2010 9:43 AM
>> To: Eran Hammer-Lahav
>> Cc: Anthony Nadalin; OAuth WG
>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>>
>> Eran,
>>
>> Both Tony and I are explaining to you what happened on the call. If you had
>> been on the call, you could have presented your view on how to proceed
>> with the calls.
>> While you may have a different opinion on how to proceed (which I am NOT
>> arguing with), arguing with us on what happened on the call seems pointless.
>>
>> -- Dick
>>
>> On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote:
>>
>> > Hi Anthony,
>> >
>> > The problem with this approach is that it hasn't worked (multiple times)
>> before because no one ever wants to do the work of collecting and writing
>> the use cases. What we get instead are short cryptic lists and pointers to
>> edge cases. We have a good grasp on how OAuth 1.0 is used and its
>> limitations as addressed by the WRAP draft.
>> >
>> > The best use of my time is to continue working on the drafts and asking
>> technical questions whenever a decision is needed. If and when someone
>> writes use cases, I will review those and see if they are supported by the
>> drafts.
>> >
>> > I will leave it up to the chairs to decide how they want to guide the
>> > working
>> group.
>> >
>> > EHL
>> >
>> >> -Original Message-
>> >> From: Anthony Nadalin [mailto:tony...@microsoft.com]
>> >> Sent: Wednesday, February 03, 2010 9:02 AM
>> >> To: Eran Hammer-Lahav; Dick Hardt
>> >> Cc: OAuth WG
>> >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
>> >>
>> >> I would tend to agree with Dick based upon the last call and where
>> >> that was heading. I believe that Eve had some use cases to share
>> >> around UMA
>> >>
>> >> -Original Message-
>> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
>> >> Behalf Of Eran Hammer-Lahav
>> >> Sent: Wednesday, February 03, 2010 8:41 AM
>> >> To: Dick Hardt
>> >> Cc: OAuth WG
>> >> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>> >>
>> >> Has anyone gathered and reviewed use cases? I haven't seen much of
>> >> that showing up on the list. From my experience, asking people for
>> >> use cases rarely works, unless someone is willing to do the work and
>> >> collect them (and so far I haven't heard from such volunteer). I much
>> >> prefer the process in which we produce a technical document based on
>> >> OAuth 1.0 and the new requirements as defined by WRAP, and discuss
>> >> use cases as a property of the technical attributes of this draft.
>> >>
>> >> Of course, you don't have to agree with me, but that puts the burden
>> >> of producing use cases documentation on you and others interested in
>> >> taking that approach. We certainly have room for both, and keep in
>> >> mind that my token draft is not (yet) a working group item.
>> >>
>> >> The indication I received from many of the active members of this
>> >> list is that we have a strong desire to show up at Anaheim with two
>> >> stable drafts. I think we are very close to getting the
>> >> authentication piece done following much of OAuth 1.0 functionality
>> >> (only cleaner and better structures), as well as treating bearer
>> >> tokens as first class citizens. Given that no one has started a
>> >> discussion about the delegation flows to include, I d
[OAUTH-WG] Proposed agenda for third interim meeting
Hi all,
Below is a very rough agenda for Thursday's interim meeting. Your
feedback is very welcome to improve this agenda, either on the list or
during the meeting ("agenda bashing").
Peter and I have included a request for a scribe; if anyone would like
to volunteer beforehand, we'd be very grateful as it will maximize our
time on the call.
The logistics are available here:
http://www.ietf.org/mail-archive/web/oauth/current/msg01166.html -
Please note the time, which is earlier than the last call, at 18:30
GMT, 10:30 PST, and 13:30 EST.
*
AGENDA
* Intro
* NOTE WELL
* request for a scribe
* Agenda bashing
* Chair announcements
* impending Area Director change
* wiki pages (use cases, terminology)
* call for agenda items at Anaheim meeting
* Continuation of "use a token" discussion
* Continuation of use case discussion
* Scheduling of next interim meeting
* Other business?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
