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