- WG-UMA - mailman.kantarainitiative.org

Notes from UMA telecon 2016-12-115
by Eve Maler 15 Dec '16

15 Dec '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-15 MinutesRoll call Quorum was not reached. Critical mass was reached. Approve minutes Approve minutes of UMA telecon 2016-12-01 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01>: Deferred. Logistics - *Dec 16:* Legal subgroup meets as usual - *Dec 22:* meet as usual; RSVP – Dec 23: no Legal subgroup meeting Who's not available for next Thursday? Andi, Cigdem, François. Work on UMA.next issues * Use Cases for FHIR Security Authorization with Patient Consent <http://kantarainitiative.org/confluence/download/attachments/17760302/Use%2…> (aka "cascading OAuth"):* Mike Davis is the security architect for the Dept of Veterans Affairs. Kathleen, Mohammad, and Tony are on the security architecture team and have been working on enabling patient choice. What they'll show is what they've been working on for the HIMSS '17 conference. They've developed a profile that integrates patient and enterprise access control systems. Kathleen notes that Adrian has articulated the "multiple portals problem" in the past. The Word document linked from above "cascades" authorization decisions. This version of the doc makes both parts OAuth-based, where the token expires within a period of time. They had demonstrated UMA in 2015. This next level is where there are multiple authorities governing access – different sources of policy. The VA is a US federal agency. As such, it makes its IP available freely. The notion is that there are at least two AS's. There is an external third-party authorization server connect to a consent directive management system. A "consent directive" is an authorization policy stored in a FHIR server in FHIR-dictated form. That's not UMA, but a FHIR server has the capability to query that in order to enforce a decision. The flow starts with a client requesting some data. The client is redirected, or is hinted to go to the local AS, where it asks for an RPT. At this point, the overarching policies in the organization are checked. It's determined whether the patient's consent is needed. If so, a second hint is produced after the token is issued, and it proceeds to get a "patient consent token", which here is called an RPT. Verification and introspection later needs to take place, with each relevant AS. Data labeling and transformation subsequently takes place, which is not related to UMA. They have a beta implementation of this right now. Adrian: What is the resource that is being registered? There's the HEART profile, and the Argonaut profile. These talk about what you're supposed to register in terms of the permission structure. What goes into the scope portion is basically the security labels. If you're only supposed to have non-confidential data, that goes in. The resource ID portion, according to the spirit of HEART and other profiles, that gets registered is Alice/Medication, followed by the necessary clearances. It's a standard UMA server. What connects the AS's is the patient identity. This allows finding the relevant policies that the patient has filed. Eve: If these are UMA AS's, are these all RPTs, and are the hints all need_info hints? This is still classic UMA, and this is all being done with permission registration (which would now be called requesting permissions on behalf of the client), only having a different party making the request. Eve suggests that a next step could be a detailed message flow for the swimlane and numbered list on pages 11-12 of the Word document. Colin: Encourages looking at Consent Receipts as well. Eve: Is this a way for an RS to constrain what an RO can share so as to control its liability in a technical, vs. just legal fashion? Kathleen: Yes, but it's also a way to ensure central patient policy *information* management of their own policies per se, not just have a central administration point. Next steps: Decide if we want to make this a part of UMA2. *Set math:* Decision 1: What to do when the client has pre-registered parsimoniously but the rest of the scope ecosystem has been more generous? 1. Client pre-registers for scopes at the AS (dynamically, or out of band, or updates a previous registration, etc.) 2. Client attempts access, nominally "using some scope" by virtue of making an API call 3. RS requests one or more permissions on the client's behalf 4. Client requests an RPT, possibly explicitly requesting one or more scopes 5. (At some point) RO configures the AS with some policy conditions, which would ultimately grant the client (on the RqP's behalf) some permissions with some scopes 6. AS grants the client (on the RqP's behalf) permissions with some scopes 1a. *What if, in #1, client registers for only A, B, C, but in #3 and/or #5, the AS gets the idea that it's supposed to grant a permission that involves scope X?* 1b. *What if (given the RO/RS context above), in #4, client requests X even though it only registered for A, B, C?* Note that there is no requirement that a client has to pre-register for scopes. And there's no hard semantic for scope pre-registration, so the act doesn't necessarily mean "I can handle only these scopes". And we can fast see the day coming where scope pre-registration becomes so awkward because of its implicit association with only some resources in many OAuth-protected APIs that *resource* pre-registration will become available (scopes are *explicitly* associated with specific resources in UMA already). Eve had tried a "least privilege" strawman in email was to mask out scope X from any client that didn't pre-register for it. But we can't seem to think of a reason to deny granting that permission. Mike S could imagine a really paranoid trust model that would have the AS deny granting it, though. So do we want to be deterministic, or continue to allow the AS to use discretion? E.g., see the wording in Core V1.0.1 Sec 3.5.2 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#authorizati…> about partial fulfillment of scopes vs. rejection. Ishan: At least coming up with a maximal list of scopes and saying it's okay to mask it or not would be *more*deterministic. If an UMA AS is also an OIDC OP, would conflicts arise? We don't want that. (The WG call officially ended, and Eve Cigdem continued.) 1c. *What discretion or determinism should there be around #3?* In Core V1.0.1 Sec 3.2 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#register-pe…>, we currently say that the RS has to request a permission that at least suffices for what the client attempted. Of course, there is even some discretion in figuring this out. But it still seems practical to continue requiring the RS to request something minimally sufficing, and then – because it alone is authoritative for resource boundary management and complexity – enabling requesting of multiple permissions (that is, multiple resources) as required or desired, along with multiple scopes on those resources, based on its judgment as we have been saying all along. It's a matter not only of resource boundary management but also of stinginess/permissiveness. Client pre-registration of scopes seems so discretionary and so unclear as to its purpose that we think it shouldn't be relied on as any guidance towards UMA normative text. Maybe in future, it *might* be more meaningful if an RS could register its resources for protection in a way that allows clients to pre-register for *resources with scopes* (generically, outside of an RO context). But for now, this isn't possible. At that later time, we could extend UMA to allow clients to request specific resources when asking for an RPT in #4. We're not willing to define this mechanism as an extension to dynamic client registration, or as an OOB mechanism. (Or are we? A way to do it either dynamically or OOB would be to use something like the optional RReg type property (see RSR V1.01. Sec 2.2.1 <https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#c…>), or an extension scopetype property or whatever, to convey the generic resource type you mean. From there, you could drill down on the scopes you mean, with an array. Etc. A client could use an object that leverages all this stuff to pre-register in some fashion for the specific scopes it can handle. Probably way too ambitious for UMA2, but there's an obvious path for how to extend it if someone wants to do this.) The way we're heading in our logic, #4 – the client requesting scopes – is something that's kind of unattractive because of this scope/resource skew. However, we had made this decision to add it because OAuth allows it, and because of the presumption that the client "knows its own mind", has to know the API, and therefore has to code to the scopes. Should we consider the above analysis to be sufficient new information to make us reconsider the new functionality we've added (client requesting scopes at the token endpoint, and the associated invalid_scope error)? Or should we consider it directly relevant to the AS's calculation, as in *1b* above? It's a kind of dynamic addition to whatever is in the permission ticket. The client – presumably acting on behalf of the RqP no matter whether the RqP is human or enterprise – has two opportunities to express the latter's wishes, or perhaps three. In #1, pre-registration for scopes is an act that takes place outside of any RqP's context, so that has nothing to do with the RqP, so let's not count that. In #2, the client actually attempts access, so that's a direct expression of a wish for access of a particular kind to something, directly at the RS itself. So we should take that very seriously (and do, according to the discussion above). In #4, the client currently has the ability to request scopes, a la OAuth, though we haven't been super-clear about the semantic of such a request: is it on the RqP's behalf, or is it on the client's own behalf, or what? Our previous discussion leading to this decision leans more on the side of the client's own behalf, connected somewhat to things like pre-registration. So, how much do we actually care – in set math reality – what the client requests at token-endpoint run time? Is it more important than pre-registration for scopes, and if so, by how much? *AI:* Eve and Cigdem: Draft sample spec text for "set math", with a choice point between client scope request effect options. Attendees As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah) 1. Andi 2. Eve 3. Mike S 4. Cigdem 5. Sarah Non-voting participants: - Andrew - Ishan - Adrian - François - Kathleen - Scott F - Mike Davis - Jin Guests: - Tony Mallia - Colin Lurking - Mohammad Jafari Regrets: - Sal - James - Domenico *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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