Re: [WG-UMA] Profile v. Framework

Sooner or later we're going to need to reconcile UMA with some kind of interoperability claim. HEART has spent almost two years and we're nowhere near done. Who do we expect will create interoperability claims around UMA? Debating profile v. framework is bike-shedding. Adrian On Thu, Dec 1, 2016 at 6:48 PM, Eve Maler wrote:

The term "application" is a good compromise, perhaps, given that it has the sense of implementing a particular scenario without also implying that it's a subset in total (per RFC3339 etc.). I've sometimes used "a profile or application of OAuth" to describe UMA in conversations.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Dec 1, 2016 at 2:28 PM, John Bradley wrote:

...

For what its worth, I agree with Justin about the way Connect is both a profile of and extension to OAuth 2. Some of the extensions have been adopted by OAuth and will eventually be re-spun as profiles.

We were very careful in Connect to avoid violating any MUST in the OAuth spec. Sometimes that forced some workarounds that may not have been the easiest way to do things.

So yes I have called Connect both a profile of OAuth as it clearly restricts some options like redirect_uri matching and JWT claims (remember JWT is also a OAuth spec) while also being a superset with discovery registration and a API. So it is in many ways a application that uses OAuth like any other application , but documented for interoperability.

John B.

...

On Dec 1, 2016, at 7:17 PM, Justin Richer wrote:

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

...

and naming conventions." In the SAML sense, a profile is used to "implement a scenario". For example, the XACML SAML profile "facilitates

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 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

...

http://www.iana.org/assignments/oauth-parameters/oauth-

...

Plus, OpenID Connect defines the id_token and Hybrid Flow, which are obviously not specified in OAuth 2.0. Can OpenID Connect be futher

+/- 50 IANA registrations for OpenID COnnect: parameters.xhtml 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

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/