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(a)gluu.org>, wg-uma(a)kantarainitiative.org
References: <69fa5e4e659e6ef5352a7a141dc82ec4(a)gluu.org>
From: Justin Richer <jricher(a)mit.edu>
Message-ID: <e2f9b8e1-c29d-d66a-8977-7bff158b35b8(a)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(a)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(a)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(a)gluu.org
> http://support.gluu.org
> _______________________________________________
> WG-UMA mailing list
> WG-UMA(a)kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
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(a)gluu.org>, wg-uma(a)kantarainitiative.org
References: <69fa5e4e659e6ef5352a7a141dc82ec4(a)gluu.org>
From: Justin Richer <jricher(a)mit.edu>
Message-ID: <e2f9b8e1-c29d-d66a-8977-7bff158b35b8(a)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(a)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(a)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(a)gluu.org
> http://support.gluu.org
> _______________________________________________
> WG-UMA mailing list
> WG-UMA(a)kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
