Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23
h...@inf.ed.ac.uk (Henry S. Thompson) writes: Barry Leiba writes: OK, I now recognise a culture clash as the underlying point at issue, so this spec. is the wrong place to address it. Ah... so if the issue is how IANA makes registry information available Precisely. then please go to the happiana mailing list ( https://www.ietf.org/mailman/listinfo/happiana ) and see if you can work with Michelle and the other IANA folks on it. Indeed. I should have realised that that was the right level sooner: as I said, thanks for your patience. If you need help coordinating with Michelle @ IANA I can help coordinate a meeting in Paris next week (assuming you are attending). ht -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth WG Re-Chartering
Hi Paul, for me, your proposal looks like the natural counterpart of JWT, as it standardizes the way to implement handle-based token designs (in contrast to self-contained tokens). therefore +1 from my side. regards, Torsten. Am 15.03.2012 11:35, schrieb Paul Madsen: +1 to defining RS-AS interactions. We've implemented such a 'token introspection' endpoint in our AS and I'm be happy to no longer need to explain to customers/partners why it's not part of the standard. As input, an (incomplete) spec for our endpoint enclosed. (we modeled the verification as a new grant type, leveraging as much as possible the existing token endpoint API) Wrt the 5 item limit 1) is this an arbitrary #? if people sign up to work on more items, could it be extended? 2) the use cases document seems already well progressed (and informational). Need it count against the 5? paul On 3/14/12 5:53 PM, Richer, Justin P. wrote: Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together. Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several token introspection endpoints in various implementations. -- Justin On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote: So, here is a proposal: --- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (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 and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] DoneSubmit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item DoneSubmit 'HTTP Authentication: MAC Authentication' as a working group item DoneSubmit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard DoneSubmit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] Jun. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Apr. 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the
Re: [OAUTH-WG] OAuth WG Re-Chartering
In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec. regards, Torsten. Am 15.03.2012 16:00, schrieb Eran Hammer: I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS-RS work is probably simpler and more useful at this point. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, March 15, 2012 4:47 AM To: ext Blaine Cook; Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering Hi Blaine, These are indeed good requirements you stated below. When you look at the list of topics do you think that the proposed items indeed fulfill them? Ciao Hannes -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of ext Blaine Cook Sent: Thursday, March 15, 2012 1:31 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering On 14 March 2012 20:21, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: So, here is a proposal: [Editor's Note: New work for the group. 5 items maximum! ] Aug. 2012Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard Nov. 2012Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard Nov. 2012Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration Jan. 2013Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard Sep. 2012Submit '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 ___ 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] OAuth WG Re-Chartering
Hi Hannes, +1 You have compiled a list of meaningful and feasible objectives. regards, Torsten. Am 14.03.2012 21:21, schrieb Hannes Tschofenig: So, here is a proposal: --- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (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 and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] DoneSubmit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item DoneSubmit 'HTTP Authentication: MAC Authentication' as a working group item DoneSubmit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard DoneSubmit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] Jun. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Apr. 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard Apr. 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard Apr. 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard May 2012Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC [Editor's Note: New work for the group. 5 items maximum! ] Aug. 2012Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] Nov. 2012Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token] Nov. 2012Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] Jan. 2013Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] Sep.
Re: [OAUTH-WG] OAuth WG Re-Chartering
I don't think dynamic registration completely removes the need for a public client, that can't keep secrets. While we did do dynamic client registration for Connect that is a more constrained use case. I would put JWT and AS-RS communication as higher priorities than dynamic registration. Partially because they are more self contained issues. John B. On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote: In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec. regards, Torsten. Am 15.03.2012 16:00, schrieb Eran Hammer: I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS-RS work is probably simpler and more useful at this point. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, March 15, 2012 4:47 AM To: ext Blaine Cook; Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering Hi Blaine, These are indeed good requirements you stated below. When you look at the list of topics do you think that the proposed items indeed fulfill them? Ciao Hannes -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of ext Blaine Cook Sent: Thursday, March 15, 2012 1:31 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering On 14 March 2012 20:21, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: So, here is a proposal: [Editor's Note: New work for the group. 5 items maximum! ] Aug. 2012Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard Nov. 2012Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard Nov. 2012Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration Jan. 2013Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard Sep. 2012Submit '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 ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth WG Re-Chartering
+1 to JWT and AS-RS communication over dynamic registration On 3/21/12 3:52 PM, John Bradley wrote: I don't think dynamic registration completely removes the need for a public client, that can't keep secrets. While we did do dynamic client registration for Connect that is a more constrained use case. I would put JWT and AS-RS communication as higher priorities than dynamic registration. Partially because they are more self contained issues. John B. On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote: In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec. regards, Torsten. Am 15.03.2012 16:00, schrieb Eran Hammer: I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS-RS work is probably simpler and more useful at this point. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, March 15, 2012 4:47 AM To: ext Blaine Cook; Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering Hi Blaine, These are indeed good requirements you stated below. When you look at the list of topics do you think that the proposed items indeed fulfill them? Ciao Hannes -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of ext Blaine Cook Sent: Thursday, March 15, 2012 1:31 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering On 14 March 2012 20:21, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: So, here is a proposal: [Editor's Note: New work for the group. 5 items maximum! ] Aug. 2012Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard Nov. 2012Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard Nov. 2012Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration Jan. 2013Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard Sep. 2012Submit '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 ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Google using JTW assertions?
I noticed this post http://googledevelopers.blogspot.se/2012/03/service-accounts-have-arrived.html, via a tweet from a colleague, that mentions sending a JWT to Google’s OAuth 2.0 Authorization Server in exchange for an access token. The post mentions compliance of draft 25 of OAuth v2 but doesn't give much more detail. I'm wondering if any Google folks on this list know if it was implemented to the http://tools.ietf.org/html/draft-ietf-oauth-assertions http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer specs? It would be great to have some feedback one way or the other on the applicability of those documents from a real world deployment. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
