by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uB1MHES2030033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Dec 2016 17:17:16 -0500 To: Mike Schwartz <mike@gluu.org>, wg-uma@kantarainitiative.org References: <69fa5e4e659e6ef5352a7a141dc82ec4@gluu.org> From: Justin Richer <jricher@mit.edu> Message-ID: <e2f9b8e1-c29d-d66a-8977-7bff158b35b8@mit.edu> Date: Thu, 1 Dec 2016 17:17:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <69fa5e4e659e6ef5352a7a141dc82ec4@gluu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrJu70CHC4NNyEYs5r5axWUw+9pnF gclj/SV/j1WbO9kCmKK4bFJSczLLUov07RK4Mt5dm8ZWcFG9Yv3Mw4wNjI/luxg5OSQETCRu 9x5l7mLk4hASaGOSOHj3LxOEs4FRomPlXUYI5zaTxN4f55lAWoQFtCQu/JzF0sXIwSEiYC/R 980AJCwkYC5x7Ox1dhCbTUBVYvqaFrByXgEriQevLrGB2CwCKhIPb80CqxEViJH4tO4vO0SN oMTJmU9YQGxOAQuJ9Xvfg9UzC9hK3Jm7mxnClpfY/nYO8wRG/llIWmYhKZuFpGwBI/MqRtmU 3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2MoHBkd1HawTjxn9chRgEORiUe3hfGDhFC rIllxZW5hxglOZiURHkf6QGF+JLyUyozEosz4otKc1KLDzFKcDArifDmLQDK8aYkVlalFuXD pKQ5WJTEeRncv4YLCaQnlqRmp6YWpBbBZGU4OJQkeP/OB2oULEpNT61Iy8wpQUgzcXCCDOcB Gu4INry4IDG3ODMdIn+KUZdj2rPFT5mEWPLy81KlxHm3ghQJgBRllObBzQGlkYS3h01fMYoD vSXMexBkHQ8wBcFNegW0hAloScd1e5AlJYkIKakGRjbusKP5T5pTxZ/ZqD5j2xbh8Ktm9txD O0rC3Gd6StrLGtraKBb+mHg4utDhk9/txAILuSPPuq9YqP08W1NfJ8n69MGGty2Mh5wt+hTL X+lGxZzp/HK4oX6qh6x8UgvvgjUHNcQkLQ+lT9GJ9Ldj47KcXMnMK78oK0P1X7VC0RyWMkdG nhYlluKMREMt5qLiRABXPxkX/gIAAA== Subject: Re: [WG-UMA] Profile v. Framework X-BeenThere: wg-uma@kantarainitiative.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the User Managed Access WG mail list." <wg-uma.kantarainitiative.org> List-Unsubscribe: <http://kantarainitiative.org/mailman/options/wg-uma>, <mailto:wg-uma-request@kantarainitiative.org?subject=unsubscribe> List-Archive: <http://kantarainitiative.org/pipermail/wg-uma/> List-Post: <mailto:wg-uma@kantarainitiative.org> List-Help: <mailto:wg-uma-request@kantarainitiative.org?subject=help> List-Subscribe: <http://kantarainitiative.org/mailman/listinfo/wg-uma>, <mailto:wg-uma-request@kantarainitiative.org?subject=subscribe> X-List-Received-Date: Thu, 01 Dec 2016 22:17:18 -0000 The definition that I quoted today and I believe to be correct is found in RFC3339 (among other locations): The following section defines a profile of ISO 8601 for use on the Internet. It is a conformant subset of the ISO 8601 extended format. That is to say, a "conformant subset". This is pretty consistent with the use of "profile" in the world of standards definitions. (Please don't conflate the discussion with unrelated uses of the same word, like "racial profiling".) From your own examples, both SAML profiles and OIDC *do* specify subsets of functionality of the protocols that they profile. For SAML, the profiles take from the large swath of possible expressions in the SAML language to solve specific cases. These profiles fully conform to the SAML language and yet use a subset of said language in specific ways to get things done. From the OIDC case, it doesn't use the client credentials or resource owner credentials grant types, at all. But everything that it *does* do is conformant with OAuth. OIDC also provides additional functionality because it is its own protocol and not solely a profile of OAuth 2. Instead, it would be correct to say that OIDC *contains* a profile of OAuth 2 that limits decisions choices and functionality without breaking the underlying protocol. UMA does no such limiting, either in v1.x or current 2.x directions. In fact, UMA extends, uses, and builds upon OAuth. None of those are profiling activities. Could UMA contain a profile of OAuth 2 if it wanted to? Sure! But it doesn't -- it says "go use OAuth in these places" and "extend OAuth in these ways". In no place does it say "don't use this bit of OAuth". Yes, it's true that profiles can themselves be profiled. But just because something can be profiled does not mean that it is itself a profile, right? And if you look at UMA, so many things are so loose (claims gathering, anyone?) that it's way more open than OAuth in terms of decisions. I think "application protocol" or "framework" are appropriate here. I'm particularly sensitive to the language choice here because I once had to untangle a client who was convinced that UMA had fewer choices to make at runtime than OAuth, and as we all know that's simply not even remotely the case. This stemmed from UMA 1.x calling itself a "profile" of OAuth and the client in question interpreting that in the common fashion of "conformant subset". Once we showed them all of the ways that UMA inherits OAuth's flexibility and then adds its own on top, they realized that they had the wrong picture of the world. If we can keep people from coming up with that incorrect picture in the first place, I think it's our responsibility to do so. -- Justin On 12/1/2016 2:29 PM, Mike Schwartz wrote:
Regarding today's discussion of "framework" versus "profile":
The SAML profiles document states: "This document specifies profiles that define the use of SAML assertions and request-response messages in communications protocols and frameworks, as well as profiles that define SAML attribute value syntax and naming conventions." In the SAML sense, a profile is used to "implement a scenario". For example, the XACML SAML profile "facilitates this mapping by standardizing naming, value syntax, and additional attribute metadata."
Section 1 of OpenID Connect Core Spec: "Notably, without profiling OAuth 2.0, it is incapable of providing information about the authentication of an End-User"
Of course OpenID Connect is also a superset of OAuth 2.0. There are +/- 50 IANA registrations for OpenID COnnect: http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml Plus, OpenID Connect defines the id_token and Hybrid Flow, which are obviously not specified in OAuth 2.0. Can OpenID Connect be futher profiled... of course. But certainly it provides a mapping of OAuth 2.0 to implement a specific use case--a sign-in flow. Many times I've heard of OpenID Connect being referred to as a profile by other authors of the spec.
So the idea that a profile is a "subset" of functionality is absurd. A profile makes something more specific by elaborating on the details. And the profile itself may still be generic--hence our aversion to racial profiling.
The fact is, OAuth 2.0 is a generic framework that provides a common denominator that is useful for many applications. Clearly UMA has a specific application in mind, tries to align with OAuth 2.0, and thus IS a profile. The fact that it can be futher profiled does mean that it cannot itself be a profile.
- Mike
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org http://support.gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma