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 [email protected] On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt <[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]> > An: [email protected] > Kopie (CC): [email protected] <[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 implementations. > > > Existing implementations at Google and 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] > https://www.ietf.org/mailman/listinfo/kitten > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
