December 2016 - WG-UMA - mailman.kantarainitiative.org

Reminder - Cloud Identity Summit Call for Presentations
by Andrew Hindle 15 Dec '16

15 Dec '16

Hi Following up on Eve's kind reminder at the top of today's WG call, and with my CIS content chair hat on, here is the URL for the CIS Call for Presentations: www.cloudidentitysummit.com/cfp Submissions are due by *Friday 6th January*. If you don't have anything else exciting planned for the late December / early January period (or if you need a break from the exciting things you *do* have planned!) - I encourage you to put in a submission or two. With some much exciting work going on both from a spec. and an architecture/use-case perspective, I'm hoping to see lots of interesting proposals come through from the UMA community :) If anyone is unfamiliar with CIS and needs some background on this core industry event, please let me know. And if you are a new or infrequent presenter: we are starting a speaker mentor program this year - just put a note in your submission if you think that would be of interest to you. Thanks! --&e -- ------------------------------ Hindle Consulting Limited is a company registered in England and Wales. Company number: 8888564. Registered office: Claremont House, Deans Court, Bicester, Oxfordshire OX26 6BW, UK.

1 0

Agenda for UMA telecon 2016-12-15
by Eve Maler 14 Dec '16

14 Dec '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-15 Date and Time - *Thursdays,* 9-10am PT - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/> / code 1782540 - Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01> - 5min: Logistics for upcoming meetings (calendar <http://kantarainitiative.org/confluence/display/uma/Calendar>) and 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> check-in - *Dec 16:* Legal subgroup meets as usual - *Dec 22:* meet as usual; RSVP – Dec 23: no Legal subgroup meeting - *FYI:* End game for V2 specs looks like this: - Complete drafts ASAP in January - WG vote to publish Draft Recommendations (consider this an "implementers' draft"?) - 45-day Public Review - If no changes, LC votes to certify Draft Recommendations for All-Member Ballot - Ballot takes 14+ days - If no changes, Recommendations are prepared for publication and published - Total: if no changes, up to 90 days - Work on UMA.next issues – Core is up to 09 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html> and RReg is up to 02 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-02.html> (no changes from last meeting) - Till bottom of the hour: Presentation of new use case/profile proposal: Use Cases for FHIR Security Authorization with Patient Consent <http://kantarainitiative.org/confluence/download/attachments/17760302/Use%2…> (aka "cascading OAuth") - Set math (see active email threads) - Remove policy-specific resource/scope description properties from RReg and add as extensions in Core? - claim_token_profiles_supported: Provide real profiles for OIDC and maybe SAML? - uma_profiles_supported: What to do with the extensibility profiles? - Need to have IANA registry entries for both old uma-configuration and uma2-configuration? - Shoebox endpoint - Claims hashing - Other issue backlog review/cleanup - See the latest swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Set math discussion setup
by Eve Maler 13 Dec '16

13 Dec '16

I'd like to try and structure our discussion for talking about set math, and also a use case that is hopefully just complex enough for discussion. (If this use case spurs ideas for other contrasting/better use cases, let's try and formulate them in a similar fashion for comparison's sake.) Thanks to Vlad on the APAC sync call for helping me think this through! The relevant sequence is: - (Long before) RS publishes API and its scopes, and client is developed according to those scopes - Say anything at all about this in the spec? - (Long before) Client registers with RS/API publisher to use only those scopes it intends to use - Does this make sense to tackle in the spec at any level? - Client attempts resource access at RS with no token -- giving no further overt context to the RS about what it wants - RS requests permission(s) on client's behalf at AS, based on knowledge of the parameters of the attempt - Used to be called "registering a permission" and it had to be singular, but it's now called "requesting permissions on behalf of the client" and can be plural (multiple resources) - Right now, as it was in UMA1, we require the RS to request permissions that are "sufficient" for the client's access attempt -- this is up for discussion - Client brings permission ticket from RS to RS, requesting an RPT - Client couldn't ask for specific scopes before, but now it optionally can - After the authorization process, if success, AS grants some set of permissions - Right now, as it was in UMA1, the AS is allowed to grant some permissions or no permissions if it's the case that only some of the RO's policy conditions were satisfied -- this is up for discussion Use case: - Alice uses an UMA-protected cloud file system API (RS), with *files* and *folders* as protectable resources. - Folders have scopes *read*, *write*, and *search*. - Files have scopes *read*, *write*, and *execute*. - Folders can contain files and other folders, and any one file can more than one "folder parent". However, this is known only to the RS, not to the AS. - The RS is able to tell a distinct RO and AS for every location URI for a file or folder by means of an internal mapping process. - Alice has resources with names as follows (let's use the name as the ID, for clarity of discussion): - folder "deciduous-trees' - folder "evergreen-trees" - file "birch" in folder "deciduous-trees' - file "larch" in folder "deciduous-trees' - file "fir" in folder "evergreen-trees' - file "yew" in folder "deciduous-trees' and folder "evergreen-trees" We need to answer the following questions (and which others?): - The client attempts to read file "birch". - Presumably the RS can request permission birch:read from the AS on the client's behalf. Can it request: - birch:read+write and also larch:read+write? - *Only* deciduous-trees:read without birch:read if its access control semantics (something like "folders contain/cover files") means that access to a folder confers access to contained files? - *Only* birch:write? Our current UMA1-based wording says no since this wouldn't be sufficient for what the client attempted. - What other permutations? - The client attempts to write a change to file "yew". The RS requests permission for yew:write on the client's behalf (definitely okay). The client takes the resulting permission ticket to the AS's token endpoint. - If the client includes no scopes in its request for an RPT: - If it meets the operative policy conditions only for "write", can we assume that the AS should only ever issue a permission for yew:write? - Are there any circumstances in which having the AS "surround"/extend what the RS requested ever makes sense, such as issuing a permission for yew:read+write or perhaps deciduous-trees:write and evergreen-trees:write? - If the client includes scopes in its request for an RPT, such as read and execute (keeping in mind that the client knows nothing about resource IDs per se and that scopes can differ per "resource type" as they do in this example): - Should the RS interpret this request as referring to the "closest" applicable resource, such as the file on which access was attempted in this case? The "execute" scope only makes sense on files, not folders. What if this logic doesn't make sense in the case of some other API? (We have written up an "invalid_scope" error already, but it may be underspecified.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Client reg for scopes not including X, policy allowing scope X, claims fulfilling that policy...
by Eve Maler 12 Dec '16

12 Dec '16

(Edited the subject line and broke up this thread into two for clarity...) I *think* this subject line captures at least many of the key elements of the interesting conundrum we face here, looking at the thread below. (And notice that it doesn't say that the claims are only about the RqP vs. the client, nor that the claims are provided "live" vs. represented by proxy in a PCT. Check me if I'm wrong about those details!) Justin notes that traditional OAuth implementations draw a hard line, seeming to interpret the "different" text of 6749 only in a "reduction" sense even if it could be interpreted in an "expansion" sense as well. Some strawman thinking-out-loud: What are the reasons that a client registers for scopes in the first place? If it's to express capabilities the client can handle, is it even meaningful for a client to be granted access to a scope it can't use? If the registration for scopes acts as a per-client mask, then it's a kind of least-privilege solution that makes sense in the context of every client the requesting party uses. If the client gains more capabilities and later registers for more scopes, and then attempts access using a new scope, perhaps a PCT that's in place will easily and silently grant that client the necessary access. If the requesting party is forced through an unpleasant interactive flow or something based on poor claims management or TTL strategies, that's an argument for a higher-quality authorization server, not a more permissive release of scopes. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Dec 8, 2016 at 10:03 AM, Justin Richer <jricher(a)mit.edu> wrote: > For my action item from Eve’s post, I would suggest this wording: > > Note: In step 3, the client attempts access to a protected resource with > no token, and in step 4, the resource server requests permissions on behalf > of that client at the authorization server. In order for the resource > server to know which authorization server to approach and which PAT > (representing a resource owner) and resource identifier to supply in that > request, the API being accessed by the client needs be structured in such a > way that the resource server can derive this information from the client's > token-free access attempt. Commonly, this information can be passed through > the URI, headers, or body of the client's request. Alternatively, the > entire interface could be dedicated to the use of a single resource owner > and protected by a single authorization server. > > > As for dynamic registration and the like: yes, the client could manage its > own scopes using the registration and management protocol in RFCs > 7591/7592. Managing the client’s set of registered scopes is by and large > outside the UMA and OAuth protocols. However, the question George raised is > more subtle than that. Namely, let’s say a client registers with scopes A, > B, and C. Said client then tries to access an API with scope X. In a > traditional OAuth implementation (including ours), the client wouldn’t be > able to get a token scoped to X, because the client’s identity would limit > it to only scopes A, B, and C. However, there’s more going on with UMA: the > RqP’s claims come into play in the calculation. So let’s say that Alice > sets up a policy that Bob can fulfill, and it grants scope X. > > The core “set math” question that I’m trying to raise about this is > simple: what do we do now? Do we not issue a token with scope X because the > client wasn’t registered for it? Do we issue a token with scope X because > the RqP was able to do everything required by the policy? Or do we add > scope X to the client’s available registration somehow, so the client now > has A, B, C, and X that it can ask for in the future. If we do the latter, > is “X” in the same class of scopes as A, B, and C, or is X now in its own > bubble relegated to the context of the RqP’s claims? > > This gets even more fun when considering the claims represented by the > PCT, which effectively represent fulfillment of policies good for X on this > resource. > > — Justin > > On Dec 1, 2016, at 2:11 PM, Cigdem Sengul <Cigdem.Sengul(a)nominet.uk> > wrote: > > Just commenting on this part – I wanted to say during the call, but kept > dropping J > > “How can a client dynamically add a scope that they didn't register for in > the beginning? Or delete? Well, shouldn't that be for the client > registration protocol to figure out? But if the policy conditions have been > satisfied, maybe the authorization assessment should still result in > granting the permission with the scope requested.” > > If dynamic client registration is used, a client can update and delete its > configuration (which optionally includes a scope parameter). > > About the AS assessment – in OAuth2 (RFC 6749) it says: > “ The authorization server MAY fully or partially ignore the scope > requested by the client, based on the authorization server policy or > the resource owner's instructions. If the issued access token scope > is different from the one requested by the client, the authorization > server MUST include the "scope" response parameter to inform the > client of the actual scope granted.” > > “Different” may be understood as only scope reduction, but can it be seen > also as scope expansion (if the policy allows)? > Upon a request, then AS can return a token with a wider set of scopes – > which may amortize the cost for the client in its further interactions with > the RS (Then, should the RS stay as just “the messenger”? It just > registers the permission for what is requested and does not try to expand > the scope of the request). > I will respond separately also to set math, and use case question, which > would probably make my point more clear. > > Thanks, > --Cigdem > > >

1 0

Draft minutes of UMA telecon 2016-12-01
by Eve Maler 08 Dec '16

08 Dec '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-11-10 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10>: Moved by Andi, seconded by John: APPROVED by unanimous consent. Logistics No meetings next week at all (no Dec 8 or Dec 9 meeting). Dec 15 and Dec 16: regular meetings. Dec 22: WG meeting. Dec 23: no Legal meeting. Eve reviewed the "spec end game" timeline as shown above. Work on UMA.next issues *UMA's essential characterization:* Previously we called it a profile. Now it's called a framework, including mention of its extension grant. What's the right characterization? Though UMA has fewer MAYs and SHOULDs than OAuth, it's still general. Framework, application, extension, profile... Only profile is outright inaccurate if it's the only word used. John W suggests "make use of" instead of "leveraging". *AI:* Justin: Please look at the new Note wording in Core 09 Sec 1.4 to see if a) it's okay and b) this wording could replace some instances of the wording that now appears in multiple places in the spec. *Set math:* Eve left out a relevant step in her set math email; the set of scopes that the RS registered at the AS could have a bearing on later steps. If the client only ever registered for *n* scopes out of *m* possible ones, then even if it later asks for more, the *n* scopes are a hard mask/limiting factor. Registering for scopes is simply a part of client registration, so we don't have to talk about the mechanism at all, just the effects of it. Today, clients register for scopes, and the scopes map in some relationship to resources (API calls/endpoints) determined by the API publisher (or the open API that the publisher adheres to). The same is true of UMA, except that the relationship is reified in the RReg interface by virtue of the resource description document that is registered from RS to AS, through a resource ID. (Note that there is an I-D floated in the OAuth WG that has a similar kind of resource ID...) What's weird is registering for scopes – which describe a strange universe of resources – vs specific resources or resource types or suchlike. Apparently the OAuth WG is discussing the latter as client registration upgrades. How can a client dynamically add a scope that they didn't register for in the beginning? Or delete? Well, shouldn't that be for the client registration protocol to figure out? But if the policy conditions have been satisfied, maybe the authorization assessment should still result in granting the permission with the scope requested. Maybe we can "future-proof" against client registration getting smarter and allowing registration for resources or resource types or something. *AI: *All: Please review and respond to the "Set math discussion setup <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/sxmvh8ykU…>" email so we can decide key set math questions as expeditiously and thoroughly as possible. Instructions: - Revise abstract and intro to account for characterization discussion. - Define "resource" as separate from "protected resource". Put an xref to the Sec 1.4.3 explanation about how an RS MAY manage complex resources. Attendees As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah) 1. Domenico 2. Sal 3. Nagesh 4. Andi 5. Eve 6. Mike 7. Cigdem 8. Sarah Non-voting participants: - François - Justin - John W - George - Ariel – responsible for IAM and data protection at TIAA - Kathleen - Ishan - Scott S Regrets: - Maciej - James *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Notes from UMA legal telecon 2016-12-02
by Eve Maler 02 Dec '16

02 Dec '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-12-02 - Use case collection and impact on concept mapping - End-of-year planning and news Attending: Eve, John W, Kathleen, Ann, Paul Eve spoke with Tim Reiniger this week, and they contemplated his being able to help with our mapping and use case gathering exercise. ISO 29100 <http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumbe…> (free to download – John will provide the download site), an international standard, has definitions of the actors and roles – so this is particularly useful for our generic purposes. (Note the scenario table. Scenarios g and h involve third parties, so those are about something like "downstream" access/sharing/disclosure.) So our current thinking is that we could make good progress on this exercise in short order. We looked at GDPR <http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52012PC0011>'s Article 6 to explore its rules for enabling a processor to do its stuff. We're hoping to find use case archetypes that are ones our audience most wants to see solved, which can drive a limited number of mappings. Otherwise it will be hard to get our arms around the "toolkits" we want to create. We actually want to solve an unlimited number of use cases, only we want to do it by cleverly developing tools that are responsive and parameterizable to those use cases, using limited resources. Thinking of which use cases we want to collect: Having some health and some IoT and some public-sector is good, but we want to spread them around. See these BSC DG notes <http://kantarainitiative.org/confluence/display/BSC/2016-11+%28November+201…> for three. The NZ POC of UMA <http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Man…> has a ton. We should invite all of our privacy eagles and legal eagles to contribute their use cases from personal experience. *AI:* Eve: Talk to Colin to get the logistics into the works. After our meeting on Dec 16, we officially have no Legal meetings scheduled for the end of the year! Eve suggests publicizing ad hoc "editorial meetings" to the subgroup, and everyone joining as they can. That way, we can try and live up to our very new mission statement about 2016 deliverables. [image: (smile)] *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: Legal call tomorrow
by Eve Maler 01 Dec '16

01 Dec '16

Let's focus on use case brainstorming and collecting concept mapping questions. I have a quick update on our efforts to develop interim end-of-year deliverables. Oh, and I did update our mission statement as agreed. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Re: [WG-UMA] Profile v. Framework
by John Bradley 01 Dec '16

01 Dec '16

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 <jricher(a)mit.edu> 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 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 > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma

3 2

Profile v. Framework
by Mike Schwartz 01 Dec '16

01 Dec '16

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

1 0

None
by None 01 Dec '16

01 Dec '16

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

1 0