I agree with Phil on this one (hey, it happens!): this is a classic example of having one piece of software and many instances of it talking to many different service providers. Each of those pairings is going to need to agree on a client ID, and one would hope a client secret or equivalent. It's not feasible to pre-pack these even with a single authorization service (and Google and MS are setting a bad example here), let alone every server ever. Classical OAuth has a strong relationship between the client developer and the protected resource provider, but this relationship starts to dissolve when you're talking about common APIs. OpenID Connect is one such common API that we're seeing in the web space (and SCIM will likely be another), but the SASL work is going to open up a whole slew of "common" protected APIs that could use OAuth.
As such, dynamic registration is going to be essential for this to be interoperable and scale beyond a single provider / consumer-app pair, and it makes perfect sense for Kitten to adopt it here. -- Justin On Oct 12, 2014, at 8:37 PM, Phil Hunt <[email protected]<mailto:[email protected]>> wrote: Torsten, Big +1 to your comments. I think the SASL-OAuth work is very important work and it is the *classic* use case for OAuth Dynamic Registration. SASL clients are typically developed independently of server implementation and are meant to work with any server. This means that having a pre-negotiated client_id is pretty much impossible without dyn reg or some equivalent solution — and why do another? There may be simpler profiles you can develop specific to SASL, but I think OAuth Dyn Reg should work well for this use case. Phil @independentid www.independentid.com<http://www.independentid.com/> [email protected]<mailto:[email protected]> On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt <[email protected]<mailto:[email protected]>> wrote: Hi all, there is some discussion going on in the KITTEN WG regarding the SASL/Oauth mechanism that might be of interest for the OAuth WG as well. kind regards, Torsten. -------- Original-Nachricht -------- Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt Datum: Sat, 11 Oct 2014 13:30:48 +0200 Von: Torsten Lodderstedt <[email protected]><mailto:[email protected]> An: [email protected]<mailto:[email protected]> Kopie (CC): [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Hi all, as one of the proposers (beside Hannes) of the change, I would like to explain the rationale. > -16 is submitted, and there is one suggested change (which I was supposed to > have added in already and blew it), which is to replace section 3.2.2 with > the text (farther) below. My comments on the suggested text: > #1) I don't think the dynamic registration stuff is baked enough to want to > pull that in to the "oauth-configuration" definition. I don't want to pull it > in because I don't think dynamic registration is required for SASL/OAUTH (as > evidenced by the Google and Outlook.com<http://outlook.com/> implementations. Existing implementations at Google and Outlook.com<http://outlook.com/> are no evidence against dynamic client registration. They demonstrate that it is possible to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540. Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed. In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP, using OAuth Access Tokens. This offers the following advantages: - multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users, but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens allows to decouple service access and authentication/authorization process. So the authorization server can choose the appropriate/available mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also in the context of IMAP and the like. - Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user passwords on devices. So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security. Why does this require dynamic registration? Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate (if not unfeasible) for generic clients using standardized protocols, e.g. Thunderbird. Or do you want to register the Thunderbird deveopers with every e-Mail/Calendar-provider in the world up-front? I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic clients, but it does integrate the registration step into an overall process. That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth. Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients. So I think true interoperability calls for addition of registration as well. Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication. Beside that it is already implement in existing OpenId Connect deployments. > #2) I didn't really want to make all of the OpenID elements required but I > don't have a strong opinion here, my initial intent was to use the OpenID > Discovery format as an existing format to be re-used here but leave it > flexible. Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with the OAuth WG) discuss, which elements are really needed. > #3) I am against recommending scope names at all in any way. I would not > include the last sentence of paragraph 5 below and strike the scope names. Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully convinced whether this approach will work. But let's give it a try. kind regards, Torsten. > New text for 3.2.2: > ----------------------- > 3.2.2. Server Response to Failed Authentication > > > For a failed authentication the server returns a JSON [RFC4627] > formatted error result, and fails the authentication. The error > result consists of the following values: > > > status (REQUIRED): The authorization error code. Valid error > codes are defined in the IANA "OAuth Extensions Error Registry" > specified in the OAuth 2 core specification. > > > scope (OPTIONAL): An OAuth scope which is valid to access the > service. This may be empty which implies that unscoped tokens > are required, or a scope value. If a scope is specified then a > single scope is preferred, use of a space separated list of > scopes is NOT RECOMMENDED. > > > oauth-configuration (OPTIONAL): The URL for a document following > the OpenID Provider Configuration Information schema, as > described in Section 3 of the OpenID Connect Discovery > [OpenID.Discovery], that is appropriate for the user. The > server MAY return different URLs for users from different > domains and a client MUST NOT cache a single returned value and > assume it applies for all users/domains that the server > suports. The returned discovery document MUST have all data > elements required by the OpenID Connect Discovery specification > populated. In addition, the discovery document MUST contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function. Authorization servers MUST implement the > authorization code grant and other grant types MAY be > supported. Furthermore, authorization servers MUST implement > the ability to issue refresh tokens for use with native > applications to benefit from an abbreviated protocol exchange. > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > If the resource server provides a scope (as part of the element of > the configuration payload) then the client MUST always request > scoped tokens from the token endpoint. This specification > RECOMMMENDs the use of the following scopes: > > imap: The 'imap' scope value is used to interact with IMAP mail > servers. > > pop3: The 'pop3' scope value is used to interact with POP3 mail > servers. > > xmpp: The 'xmpp' scope value is used to interact with XMPP servers. > > > > If the resource server provides no scope to the client then the > client SHOULD presume an empty scope (unscoped token) is needed. > > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > ----------------------- > > > I think we're getting very close :) > > -bill _______________________________________________ Kitten mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/kitten _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
