Agree that they are separate. For the use case I gave the fundamental requi
Sent from my iPhone On 2012-03-15, at 9:22 AM, "Richer, Justin P." <jric...@mitre.org> wrote: >> 4) wrt revocation, we definitely see use cases (enterprise employee is >> issued long lived refresh token for a mobile SaaS app, then gets fired and >> so enterprise needs to turn off the access) but can probably achieve the >> equivalent with a SCIM 'delete user' message > > Token revocation and user deletion are completely separate issues -- there's > no real overlap here. It's about closing the session management gap (for both > access and refresh tokens) and it has nothing to do with deprovisioning a > user in a system. In many cases, there might not even be a "user" that the > token directly represents, or the client wouldn't know enough about them to > make a delete user message. And that's a very good thing -- Would you really > want to give every delegated client the ability to delete your account when > it felt like it? Absolutely not - that level of power is completely counter > to the whole point of delegated access. > > Plus, for what it's worth, it's pretty much finished already and we've > implemented the endpoint already, too. > > > To answer Hannes's original question, I think the WG's priorities from the > list ought to be, in rough order: > > 1) Revocation (for reasons above) > 2) Dynamic Registration (big need for this and several drafts already out > there to start from) > 3) JWT Bearer (it matches the profile for saml bearer and fits in the OAuth > world well) > 4) JWT, if no one else will take it (and it is basically done, and well > deployed already) > 5) Use cases (since it's informational and bound to cause some level of > controversy, I wouldn't want to see this really detract from the real > normative standards work, and don't think it should be counted against the > total) > > For other documents discussed, like XML encoding, SWD, UX, and things like > that, other avenues *may* be a better fit and I'm happy with pursuing some of > these myself. But with so much of the work on these and other documents > already done, many of the same arguments for inclusion of the above five > apply. > > -- Justin > >> On 3/15/12 7:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> >>> Hi Paul, >>> >>> Interesting stuff. Thanks for sharing your draft writeup with us. >>> >>> Could you submit the document as Internet Draft when the submission gates >>> open again? >>> The I-D submission tool will be reopened at 00h UTC, 2012-03-26. >>> >>> From the current list of items what do you consider less important? >>> >>> Ciao >>> Hannes >>> >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >>> ext Paul Madsen >>> Sent: Thursday, March 15, 2012 12:35 PM >>> To: Richer, Justin P. >>> Cc: oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering >>> >>> +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.] >>> >>> Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a >>> working group item >>> Done Submit 'HTTP Authentication: MAC Authentication' as a working >>> group item >>> Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for >>> consideration as a Proposed Standard >>> Done Submit '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 2012 Submit '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. 2012 Submit '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. 2012 Submit '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. 2012 Submit '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. 2013 Submit '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. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an >>> Informational RFC >>> >>> [Starting point for the work will be >>> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] >>> >>> >>> >>> _______________________________________________ >>> 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
