- WG-UMA - mailman.kantarainitiative.org

Notes from UMA Legal telecon 2017-06-16
by Eve Maler 16 Jun '17

16 Jun '17

Thanks to all for a lively call! http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-06-16 - Reviewing pieces of deliverable #3 - All the roles in the use cases - Names and definitions for them - Different ways to connect the legal and technical artifacts and why - The different "solar systems" in the jurisdictional universe Attending: Eve, Andrew, Kathleen, Thomas, John W, Sal, Tim *Assumption:* The resource protected by UMA is personal information. Is it always? We'd had conversations in the past about other use cases, such as that the resource is not PI but rather "confidential information", or "IP", or something else that's not "PI". This subgroup's mission makes clear that it's about "protecting privacy rights", so it suggests that other use cases, such as protecting these other kinds of information (which is useful for both natural and legal persons as resource owners), are out of scope. We should state this somewhere in the final deliverable – not that the framework couldn't reasonably (or even easily?) be extended for these purposes, but we haven't chosen to focus on them at this time. *Data Subject* shortens to DS (vs *Resource Subject* and RS), and then it wouldn't clash with *Resource Server*/RS. *Data Subject* is the canonical name in GDPR, the ISO privacy framework, and pretty much all "privacy talk" around the "trinity" of data subjects, data controllers, and data processors. Let's make it so! If you have a *Client Operator* (say, Google running a *Client*, Google Calendar) and a *Requesting Party Agent* (this is our current term under discussion) – say, Dr. Bob using the Google Calendar *Client* – who is using it under the control of the real *Requesting Party*, a hospital institution – is it abundantly clear that the CO is distinct from the RqPA? Here is how the RSO and the CO each have a legal relationship with the ASO distinct from other/higher-order relationships: - The RS gets OAuth client credentials from the AS, and there is an opportunity (currently nearly always taken) for the ASO to impose an agreement on the RSO before issuing these credentials. - Similarly, the C gets OAuth client credentials from the AS, and there is an opportunity (currently nearly always taken) for the ASO to impose an agreement on the CO before issuing these credentials. When we wrote the old Binding Obligations clauses, we put clauses having to do with the client credentials stage out of scope. However, UMA2 requires <https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#autho…> the client to take certain actions at registration time (meaning, before the requesting party – NOTE: or, requesting party agent) is wielding that client software. This means effectively that the client's interactions at that registration juncture are on the "legal stage" for us, licensing-wise – so we seem to need a new table for client credentials for each, even if we may not need model clauses for one or both. The requesting party agent note is about the fact that Alice the patient might give access to "a doctor's practice" overall to get access to her calendar for scheduling her pre-op appointment. The receptionist ultimately gains access under this policy. The receptionist isn't "the practice", but an agent of the practice doing work for hire. The calendar is being used by the receptionist (*Requesting Party Agent*) but is "operated" by Google the company (the *Client Operator*). The idea is that the CO would be bound by any license formed through the client credentials issuance timeframe, the RqPA would be bound by his/her employment agreement with the "true" RqP, and the "true" RqP would be bound by the end-to-end RPT licensing through the main UMA Legal framework. The Word doc uses "Consent License". Why not "Use License" or just "License"? In order to market the framework as being able to solve a large class of consent challenges, it seems we need not put an adjective on "License" – just talk about our solutions in other ways and parts of our framework documentation. Is it worth talking about "Data Protection Licenses"? Or maybe this is a "licensing framework", and we ultimately produce a "licensing toolkit", and hey, maybe a "licensing API" that can be called! The agreements others produce with it could be whatever kinds of agreements they need to produce! Given that the agreements others produce might be dynamic (while versionable etc.) and dynamically negotiable – while we reduce the friction to making them protective of privacy rights – we don't necessarily want to apply old-fashioned labels too soon. *Resource Owner* vs *Grantor* as a name is still an open question. HL7 uses Grantor in a way that seems to only apply when the person is the offeror (?) of license terms. But in UMA, this person could be either the offeror or accepter of license terms, based the UX. Or is that true? This is an open question. Eve is starting to suspect that, regardless of flow, the RO/G is always the offeror. If Eve's assumption is correct, the next open question Eve and Tim had discussed is: Despite the "chain of agents/legal representatives" that may exist, does the offer of license terms always rest at the Data Subject somehow? E.g.: - *Data Subject* little Johnny (2yo) - ...has an Agent/Legal Representative (she's probably the latter because Johnny's a minor) mom Alice, who sets some policies on Johnny's behalf but also - ...chose an Agent, Authorization Server Operator ShareHub, which sets up some default policies and security protections - Alice shared Johnny's EHR in selective fashion - ...with RqP research organization NYP through CO *autonomous web client* Sync4Science Scraper - ...which gives downstream access to employee researcher RqPA Charlie Alternatively: - Data Subject little Johnny (2yo) - ...has an Agent/Legal Representative mom Alice, who sets some policies on Johnny's behalf but also - ...chose an Agent, Authorization Server Operator ShareHub, which sets up some default policies and security protections - Alice shared Johnny's EHR in selective fashion - ...with researcher RqPA Charlie using *web or mobile C app* Research Viewer - who gives access to the broader research organization because of his employment relationship Is the transfer of "access grants" or of a "right"? And do we stick with "Grantor", do we move back to "Resource Owner", or change entirely to something like "Data Subject Proxy" or "Data Subject Agent"? This person may have relationships with a lot of ASOs, and in some cases it's on their own behalf, and in others it's on behalf of others. There is no UMA artifact that documents on the wire (maybe on the wire in the medical world, in some circumstances?) the relationship between these two roles. See our matrix from the 2016-03–18 telecon <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…> for all the relationships and technical artifacts. The way the NZ government solved this was to invent a "headless" account for the offline person, and then have the institution manage the account on the person's behalf. Eve's suggestion for a followup from Tim: Enumerate and recommend answers for all the outstanding questions above. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Draft minutes of UMA telecon 2017-06-15
by Eve Maler 15 Jun '17

15 Jun '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-06-15 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-05-25 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-05-25>: Deferred. Logistics - Public Comment/IPR Review period concludes on July 12 – please report any comments you have during this period - No meeting on June 22 due to Cloud Identity Summit - Who's going to CIS? Should we have a BOF? What sessions should we be aware of? Check out this nice article <https://www.kuppingercole.com/blog/reinwarth/beyond-simplistic-achieving-co…> from KuppingerCole. CIS: Justin, Eve, Mike, Colin, Sal, Mark L. Don't miss the UMA2 session on Thursday afternoon. Justin is speaking on Shadow IT on Monday, and gray lists on Thursday. There's a Kantara workshop on Monday morning, where there will be a lot of updates, and a Kantara booth (table). IRM has an updated principles paper. Eve is speaking on HEART on Thursday. Sal, Mark, and Eve are on a privacy panel Tuesday afternoon. Sarah is speaking on VoT (vectors of trust) just before the UMA talk (this is opposite the HEART talk). Mike is speaking in the Practical OIDC track on good client software Wednesday morning. Eve and others are performing in a band on the Wednesday night after the keynote. #ZZAuth, baby. Let's all promote each other's talks as the week proceeds! UMA V2.0 work - All GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> /dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> (not updated to the spec refactor)/Release Notes <http://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes>/ UIG <http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui…> /Wikipedia <https://en.wikipedia.org/wiki/User-Managed_Access> - It seems no discussion is needed on new issues #326, #327, #328 – all are editorial and none seem to have controversy (speak up if you disagree) - Issue #257: Discuss new proposal for how to write the release notes (from Eve) - Issue #287: Time to submit our IANA registry requests formally? - Issue #300: Update our IETF Internet-Drafts (or create new ones) at Recommendation status? Release notes approach: Eve's attempted approach seems reasonable enough. The categories are: Spec Reorg, Terminology Changes, AS Discovery, AS/C and RS/C Communications (basically UMA grant), AS/RS Communications (basically fed authorization), and General. An UMA2 implementation approach might involve a fresh start in any case, though Eve's feeling is that it's just due diligence to publish proper release notes, to catch small corner cases or any small bits of code reuse that got things wrong from before. Justin notes that the MPD implementation is sort of "95% there", it's just that he'd need a sponsor, or engineers thrown at it to do pull requests. This was a branch on MITREid Connect (the previous version, V1.2). It was never brought into an official release stream. Sal might reach out about that. *AI:* Eve: Send off emails to the relevant official IANA Registry email addresses regarding making the registration requests. I-Ds: Do we even need to create something like this anymore? Does anyone point people to the I-D versions anymore? Justin gives this example <https://github.com/jricher/OpenID-Connect-Java-Spring-Server>. We probably should have put links to the wiki home page into those pointer I-Ds in the first place, but oh well. Consensus not to bother. The thread with Pedro Are there any actions needed based on the various topics in that thread? - You don't do the implicit grant with UMA; you do the UMA grant itself. It allows any client type you want, unless you want to further constrain client types in some profile of the UMA grant that you write yourself. The UMA grant does have special protections within it that make it more secure – in some respects – than, say, the authorization code grant, because (e.g.) the permission ticket is obtained through an API call. - This sounds a bit related to Eve's discussion with some researchers asking why the permission ticket exists and questioning its security and usability benefits. - Also see Chapter 1 of Justin's book, available for free! - Developing a test harness and doing an UMA (assuming UMA2?) conformance program: Kantara is looking for directed funds to make this happen! Our last estimate was $60K. Maybe it could use some volunteer effort as well to defray expenses. - A while back, Gluu had done some work on figuring out a sample API to protect. - Maybe informal interop testing is what's needed before formal testing. Then again, note that the informal OIDC testing was messy and hard to manage. "Neatness" of testing would count for a lot. Leadership team elections - Terms <http://kantarainitiative.org/confluence/display/uma/Leadership+Team> expire June 23 so we should vote on positions and new annual terms by either today or June 29 All are encouraged to stand for any position they wish. *AI:* Eve: Send note to the group about positions and nominations (self- or other). Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Eve 4. Cigdem Non-voting participants: - Justin - Scott F - Colin L - Thomas Regrets: - James - John W *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Reminder: UMA Legal telecon is on for tomorrow
by Eve Maler 15 Jun '17

15 Jun '17

We're bearing down on answering key questions about the legal framework, including: - All the roles in the use cases - Names and definitions for them - Different ways to connect the legal and technical artifacts and why - The different "solar systems" in the jurisdictional universe *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-06-15
by Eve Maler 14 Jun '17

14 Jun '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-06-15 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-05-25 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-05-25> - Logistics: - Public Comment/IPR Review period concludes on July 12 – please report any comments you have during this period - No meeting on June 22 due to Cloud Identity Summit - Who's going to CIS? Should we have a BOF? What sessions should we be aware of? - UMA V2.0 work: - All GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> /dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> (not updated to the spec refactor)/Release Notes <http://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes> /UIG <http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui…> /Wikipedia <https://en.wikipedia.org/wiki/User-Managed_Access> - It seems no discussion is needed on new issues #326, #327, #328 – all are editorial and none seem to have controversy (speak up if you disagree) - Issue #257: Discuss new proposal for how to write the release notes (from Eve) - Issue #287: Time to submit our IANA registry requests formally? - Issue #300: Update our IETF Internet-Drafts (or create new ones) at Recommendation status? - Leadership team elections - Terms <http://kantarainitiative.org/confluence/display/uma/Leadership+Team> expire June 23 so we should vote on positions and new annual terms by either today or June 29 - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

For Legal eagles: links to older UMA binding obs/model clause work
by Eve Maler 14 Jun '17

14 Jun '17

In Friday's call <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…> we discussed existing work that might "fill in" sample license text. Here is what we did to date (keeping in mind that the terminology might not survive our current process, but that we pretty much need to decide all that by the time we exit deliverable #3): - The Binding Obligations <https://docs.kantarainitiative.org/uma/draft-uma-trust.html> spec (officially obsolete). You can actually search throughout to look for PAT, RPT, and (this was written in UMA1 times) AAT mentions. The AAT is a pretty good substitute for the PCT for now. - Our CommonAccord draft model text <http://source.commonaccord.org/index.php?action=doc&file=G/Kantara-UMA-Text…>. Again, it mentions the tokens specifically, and was prepared in the UMA1 era -- but it post-dates the Binding Obs. Our intent has been to prepare "model clauses" (or whatever you want to call them) using the CommonAccord parameterized prose/code system as one of our legal toolkits. Probably our main legal toolkit, with others that might look like checklists and such. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

Re: [WG-UMA] Updating to UMA 2.0
by Mike Schwartz 12 Jun '17

12 Jun '17

I still say that is not OpenID Connect... it's something else. And using the Userinfo endpoint just makes it more complicated. A back door for access to Userinfo is problematic. I think this is a really bad idea. If you want to use UMA to share identity info, great... it's made for that. But overloading the Userinfo endpoint sounds like it's opening a can of worms. - Mike > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 11 Jun 2017 07:49:39 -0700 > From: Eve Maler <eve(a)xmlgrrl.com> > To: "Kelts, David" <DKelts(a)morphotrust.com> > Cc: "wg-uma(a)kantarainitiative.org UMA" <WG-UMA(a)kantarainitiative.org>, > "Cayo, Will" <WCayo(a)morphotrust.com>, "Corrigan, Jeff" > <jcorrigan(a)morphotrust.com> > Subject: Re: [WG-UMA] Updating to UMA 2.0 > Message-ID: <1F06B01C-4887-4654-8FDB-31C4557BDE3E(a)xmlgrrl.com> > Content-Type: text/plain; charset="utf-8" > > To get more specific: If you were to use the UMA grant to protect a > UserInfo endpoint, you'd switch to using a claims interaction > endpoint, vs using an authorization endpoint, in dealing with > attempted access by a requesting party. The purpose is to vet their > access to the resource owner's UserInfo endpoint. > > (Small detail: Claims collection could also be done non-interactively.) > > Is it possible that, with UMA2 and the extension grant, this mashup > would be more straightforward than previously? > > Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756) > >> On Jun 10, 2017, at 8:51 AM, Eve Maler <eve(a)xmlgrrl.com> wrote: >> >> I'd call it user-managed access to an identity claims API (y'know, a >> "user info endpoint" :-) ). That endpoint would have the benefit of >> being already pretty well standardized, but UMA-protecting it wouldn't >> be primarily for the purpose of authentication of the user in >> question. (Actually, the OAuth authorization endpoint is still where >> that happens in OIDC...but I digress, and that's the myth problem >> Justin was talking about.) It would be primarily for the purpose of >> enabling selective sharing/constrained delegated access to that user >> info. >> >> Eve Maler (sent from my iPad) | cell +1 425 345 6756 >> >>> On Jun 10, 2017, at 6:33 AM, Kelts, David <DKelts(a)morphotrust.com> >>> wrote: >>> >>> The difference, however subtle or large, is one I'd like to >>> understand. Perhaps it's the subject of a post or blog or >>> presentation. >>> >>> Many times UMA has been suggested to us over Authorize&userinfo, for >>> example protecting the tax return file vs the user authorizing the >>> processing of their tax return. We opted for the latter (since DOR >>> already had the file). >>> >>> I'd like to know when to apply which of these where... if that >>> question made sense. >>> >>> David >>> >>> ? Sent from my iPhone >>> >>> On Jun 10, 2017, at 7:54 AM, Justin Richer <jricher(a)mit.edu> wrote: >>> >>>> UMA-protected access to UserInfo is fine, but it's not an >>>> authentication protocol and not OpenID Connect. I think we'd need to >>>> be very careful about how it's presented. OAuth has a hard enough >>>> time with the whole authentication myth. >>>> >>>> -- Justin >>>> >>>>> On 6/9/2017 10:11 PM, Eve Maler wrote: >>>>> Angry, never. :) Excited about the demand, and that UMA 2.0 looks >>>>> relevant for meeting that demand. >>>>> >>>>> Agreed about an UMA-protected UserInfo being interesting and pretty >>>>> doable. And given that it would be synergistic with UMA >>>>> authorization itself, perhaps it's finally time for interested >>>>> parties to work on that... >>>>> >>>>> BTW, don't forget that the Public Comment period closes July 12, so >>>>> if you have implementation feedback, our best chance for addressing >>>>> it would be to have comments submitted during this period. >>>>> >>>>> >>>>> Eve Maler >>>>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl >>>>> >>>>> >>>>>> On Thu, Jun 8, 2017 at 10:35 AM, Pedro Igor Silva >>>>>> <psilva(a)redhat.com> wrote: >>>>>>> On Thu, Jun 8, 2017 at 2:05 PM, Eve Maler <eve(a)xmlgrrl.com> >>>>>>> wrote: >>>>>>> Welcome back, Pedro! A few notes: >>>>>> >>>>>> Thanks, Eve. >>>>>>> Aren't many other grant types applicable to multiple client >>>>>>> types? And if someone is interested to restrict the UMA grant to >>>>>>> apply only to confidential clients by writing a formal profile, >>>>>>> we have the example of the extension Assertion Framework, which >>>>>>> gets specialized by the SAML bearer assertion profile (not that >>>>>>> the latter actually does this particular kind of >>>>>>> specialization...). >>>>>> >>>>>> Yes. You just nailed down the points I've brought to this >>>>>> discussion. Although not mentioned explicitly in UMA 2.0, we can >>>>>> authenticate clients when doing UMA Grant by pushing a previously >>>>>> issued access token. Just wanted to make it clear and confirm we >>>>>> could follow this path with a bless from the expert group. As I >>>>>> did not find anything explicitly in the specs, I found better to >>>>>> ask first before coding. >>>>>> >>>>>>> It would be good to learn more about the contexts in which you're >>>>>>> using OIDC. From time to time, we've talked about the potential >>>>>>> benefits of a sort of "OIDC or at least UserInfo endpoint that is >>>>>>> UMA-protected", because then the resource owner could share >>>>>>> standardized identity data with autonomous third parties, gain >>>>>>> positive control over that data, not have to be present when the >>>>>>> data is requested, etc. In fact, a person in a requesting party >>>>>>> role could potentially use this mechanism to protect the claims >>>>>>> sought by a resource owner's AS for authorization assessment. >>>>>> >>>>>> For sure there are a lot of benefits for resource owners in >>>>>> protecting UserInfo with UMA. And I don't think this is something >>>>>> hard to achieve if you have UserInfo and its data/claims properly >>>>>> represented as resources and scopes in the AS. >>>>>> >>>>>> I know you'll get angry with me :) But right now we don't fully >>>>>> support UMA. Our plan is now focus on updating our stuff to UMA >>>>>> 2.0 and implement the missing pieces. We have very limited >>>>>> resources to work on this and our requirements are really driven >>>>>> by demands from our community and customers. But we already had >>>>>> people asking for more features from UMA, specially those related >>>>>> with user managed access/resource sharing (the honeypot). >>>>>>> We do not yet have an interop or testing conformance program, but >>>>>>> the number of serious requests is increasing, and we put some >>>>>>> effort into this in the past. Time to pick up where we left off; >>>>>>> I will make a note to follow up. >>>>>> >>>>>> Great, thanks for the update. >>>>>> >>>>>>> >>>>>>> >>>>>>> Eve Maler >>>>>>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl >>>>>>> >>>>>>> >>>>>>>> On Thu, Jun 8, 2017 at 5:57 AM, Justin Richer <jricher(a)mit.edu> >>>>>>>> wrote: >>>>>>>> You're conflating the grant type (and its associated redirect) >>>>>>>> with public clients. They're two separate aspects of the >>>>>>>> protocol and are not tightly tied together, though you do often >>>>>>>> find one with the other. It's not "public clients" that obtain >>>>>>>> tokens from the authorization endpoint, it's "implicit grant" >>>>>>>> clients. You can use a public client with non-implicit flows if >>>>>>>> you want to -- in fact, a public client with the authorization >>>>>>>> code flow (and PKCE) is the recommended method for native >>>>>>>> applications these days. >>>>>>>> You don't use the implicit grant with UMA, you use the UMA >>>>>>>> grant. The UMA grant doesn't use the authorization endpoint at >>>>>>>> all. There is no "implicit UMA grant". If you want to use the >>>>>>>> UMA grant with an in-browser client, you can do so. The >>>>>>>> in-browser client just calls the token endpoint like any other >>>>>>>> client would. >>>>>>>> I don't understand your statement about a bearer token instead >>>>>>>> of the implicit grant -- if you're doing the implicit grant >>>>>>>> today in just about every implementation, you're getting a >>>>>>>> bearer token. And to do UMA you need to do the UMA grant anyway, >>>>>>>> so the implicit grant doesn't apply here. And there aren't >>>>>>>> standardized non-bearer tokens defined yet, so you're likely >>>>>>>> doing bearer tokens whether you're doing UMA or plain OAuth >>>>>>>> anyway. >>>>>>>> OpenID Connect is built on OAuth, not UMA. There's no definition >>>>>>>> for doing OpenID Connect on top of UMA, and I would argue that >>>>>>>> it doesn't really make sense: OpenID Connect is an identity >>>>>>>> protocol and the whole point is to delegate access to the >>>>>>>> current user's identity API, which is what OAuth does. UMA would >>>>>>>> give you access to some other party's identity API, which >>>>>>>> doesn't tell you who's logged in right now. While they're often >>>>>>>> used together, they solve very different use cases. Think of it >>>>>>>> like having a hammer, a saw, and a screwdriver in the toolbox. >>>>>>>> They're all there for different reasons but you can use them all >>>>>>>> to build your cabinet or whatever. >>>>>>>> >>>>>>>> Hopefully this helps untangle some things. >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>>> On 6/8/2017 7:29 AM, Pedro Igor Silva wrote: >>>>>>>>> OK. Thanks, Justin. >>>>>>>>> >>>>>>>>> OAuth2 spec does cover public clients, which are usually >>>>>>>>> related with usage of a implicit grant. But in UMA 2.0 it seems >>>>>>>>> we have now a specific grant type, which flow and examples are >>>>>>>>> really specific to confidential clients. And more important, >>>>>>>>> UMA grant type does not seem to support redirection which is >>>>>>>>> something essential if you want to support public clients. >>>>>>>>> Based on OAuth2 specs, public clients are able to obtain tokens >>>>>>>>> from the authorization endpoint (not token endpoint) based on >>>>>>>>> their client_id and redirection_uri when using implicit grant. >>>>>>>>> >>>>>>>>> Like I previously mentioned, to avoid using implicit grant we >>>>>>>>> would just support a bearer token when using UMA grant type >>>>>>>>> (and token endpoint). Some of our use cases are related with >>>>>>>>> public clients authenticating with Keycloak based on OpenID >>>>>>>>> Connect where an ID token and AT is already available to them. >>>>>>>>> >>>>>>>>> One last question, this one about UMA compliance. We would like >>>>>>>>> to include Keycloak in the list of UMA implementations after >>>>>>>>> reviewing what we have in order to conform with latest version >>>>>>>>> of the spec. Is there a TCK or some other process we need to >>>>>>>>> follow to achieve this ? >>>>>>>>> >>>>>>>>>> On Wed, Jun 7, 2017 at 10:27 PM, Justin Richer >>>>>>>>>> <jricher(a)mit.edu> wrote: >>>>>>>>>> There?s nothing in the spec about public clients because it?s >>>>>>>>>> all covered in OAuth 2 (RFC6749 specifically). >>>>>>>>>> >>>>>>>>>> ? Justin >>>>>>>>>> >>>>>>>>>>> On Jun 7, 2017, at 12:57 PM, Pedro Igor Silva >>>>>>>>>>> <psilva(a)redhat.com> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Wed, Jun 7, 2017 at 12:21 PM, Justin Richer >>>>>>>>>>>> <jricher(a)mit.edu> wrote: >>>>>>>>>>>> That is not correct. You can have a public client in UMA >>>>>>>>>>>> 2.0, and in fact you inherit all of the various OAuth client >>>>>>>>>>>> types and authentication methods since you?re talking >>>>>>>>>>>> directly to the token endpoint to get the RPT instead of a >>>>>>>>>>>> special thing. But remember, you needed to talk to the AS to >>>>>>>>>>>> get an AAT previously anyway, so you?ve already needed to >>>>>>>>>>>> have those bits in place in your client. >>>>>>>>>>>> >>>>>>>>>>>> Really, do whatever you?d have done previously to get the >>>>>>>>>>>> AAT (which required an OAuth transaction with the token >>>>>>>>>>>> endpoint) and use it with the token endpoint to get the RPT >>>>>>>>>>>> now. So you always needed a client ID before anyway, that?s >>>>>>>>>>>> not new, and now you can use your secret or key or nothing >>>>>>>>>>>> just like you used to, but in a different part of the >>>>>>>>>>>> process. >>>>>>>>>>> >>>>>>>>>>> Yes, use the AAT with the token endpoint is what I have in >>>>>>>>>>> mind. If that is fine and still in sync with the spec for me >>>>>>>>>>> is fine. But, is there anything in spec about public clients >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Is it recommended that you use a confidential client where >>>>>>>>>>>> possible? Definitely, as the increased security is well >>>>>>>>>>>> worth the minimal effort that?s usually required. There are >>>>>>>>>>>> a lot of cases where it doesn?t make sense though, like a >>>>>>>>>>>> browser or native app that?s not using dynamic registration. >>>>>>>>>>>> In any event, this is all now directly inherited from OAuth >>>>>>>>>>>> instead of being reinvented from OAuth, as it was in 1.0. >>>>>>>>>>> >>>>>>>>>>> That is exactly one of the use cases we need to support. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ? Justin >>>>>>>>>>>> >>>>>>>>>>>>> On Jun 7, 2017, at 10:58 AM, Pedro Igor Silva >>>>>>>>>>>>> <psilva(a)redhat.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> It has been a long time since my last message to this >>>>>>>>>>>>> group. Since then we have implemented quite a few things in >>>>>>>>>>>>> Keycloak [1] in order to support fine-grained permissions >>>>>>>>>>>>> and UMA 1.0. >>>>>>>>>>>>> >>>>>>>>>>>>> We are not full compliant yet and some pieces are still >>>>>>>>>>>>> missing in our implementation. But we already have the >>>>>>>>>>>>> backbone to start implementing now the rest of the spec. >>>>>>>>>>>>> >>>>>>>>>>>>> One of my main tasks is now update our implementation to >>>>>>>>>>>>> UMA 2.0 and it seems that one of the main changes is >>>>>>>>>>>>> related with the removal of AAT in favor of a specific >>>>>>>>>>>>> grant type for UMA. >>>>>>>>>>>>> >>>>>>>>>>>>> In UMA 1.0 clients were not really forced to authenticate >>>>>>>>>>>>> using client credentials when interacting with the RPT >>>>>>>>>>>>> endpoint (Authorization API), but just use a AAT as a >>>>>>>>>>>>> bearer token. Now, with UMA 2.0, it seems that clients >>>>>>>>>>>>> really need to be confidential and use its credentials >>>>>>>>>>>>> (e.g.: id/secret or jwt) to authenticate with the token >>>>>>>>>>>>> endpoint when using UMA Grant. >>>>>>>>>>>>> >>>>>>>>>>>>> Is that correct ? >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> https://keycloak.gitbooks.io/documentation/authorization_services/index.html >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> Pedro Igor >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> WG-UMA mailing list >>>> WG-UMA(a)kantarainitiative.org >>>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>> >>> >>> This message is only for the use of the intended recipient and may >>> contain information that is CONFIDENTIAL and PROPRIETARY to >>> MorphoTrust USA, LLC. If you are not the intended recipient, please >>> erase all copies of the message and its attachments and notify the >>> sender immediately. >

3 2

Updating to UMA 2.0
by Pedro Igor Silva 11 Jun '17

11 Jun '17

Hello, It has been a long time since my last message to this group. Since then we have implemented quite a few things in Keycloak [1] in order to support fine-grained permissions and UMA 1.0. We are not full compliant yet and some pieces are still missing in our implementation. But we already have the backbone to start implementing now the rest of the spec. One of my main tasks is now update our implementation to UMA 2.0 and it seems that one of the main changes is related with the removal of AAT in favor of a specific grant type for UMA. In UMA 1.0 clients were not really forced to authenticate using client credentials when interacting with the RPT endpoint (Authorization API), but just use a AAT as a bearer token. Now, with UMA 2.0, it seems that clients really need to be confidential and use its credentials (e.g.: id/secret or jwt) to authenticate with the token endpoint when using UMA Grant. Is that correct ? [1] https://keycloak.gitbooks.io/documentation/authorization_services/index.html Thanks. Pedro Igor

4 13

Re: [WG-UMA] Updating to UMA 2.0
by Mike Schwartz 10 Jun '17

10 Jun '17

Can you use the UMA grant to protect Userinfo? I had this same thought a year back. But if you don this, I think it's some other identity API. - Mike

1 0

Notes from Legal telecon 2017-06-09
by Eve Maler 09 Jun '17

09 Jun '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-06-09 - Reviewing pieces of deliverable #3 Attending: Eve, Colin, Tim, John W, Mark L, Kathleen The new matrix maps UMA consent licenses to key concepts in various regulatory regimes. How can we vet the correspondences? Can we see UMA as another chapter in the millennia-old commercial legal system? "Open" licenses are freely transferrable. "Limited" licenses limit the use to one specific user. Tim threw in duration as well, under "Non-Transferable". John points out that stopping the usage at one stop could be problematic because then a data controller couldn't ever go on and share with a data processor. Scenario: RO Alice chooses to share certain files (say, scanned receipts) from digital file system service Dropbox (an RS) to accountant (RqP) Bob, where Bob is using client app TurboTax. (Alice also happens to use TurboTax sometimes.) Alice's AS is ShareHub. Eve's question is: Is Bob a Data Processor? Or is Bob another Data Controller? Could there be different licenses for either circumstance? Regarding our artifacts: - The PAT (where Alice's AS and RS, ShareHub and Dropbox in this case, get associated together) is an OAuth access token, so it's an *opt-in flow* where Alice (typically) has no choice about the terms. The reason this may matter is that we might have limited ability to affect *OAuth's* parameters of a "legal framework", vs. UMA's. - On the other hand, the RPT (where Alice's policy conditions dictate the specific permissions and their durations) has a more discretionary nature. She has choice and control, to the extent of the AS's policy condition capabilities. (Those capabilities are in the "competitive space". See UMA Grant Sec 3.3.4 <https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#autho…>, second Note text. This allows AS's to compete on policy condition handling.) - The PCT probably doesn't have any of the same categories that the PAT and RPT have. It's a simple token, actually a OAuth-like, which would have different rows. Is there *always*, *sometimes*, or *never* a transfer of accountability where the RqP becomes another Data Controller? The use cases we collected earlier, to her mind, seem to include both kinds. Mark brings up the case of consenting to sharing data for marketing purposes in this context. Kathleen thinks consumers won't get subtleties (and Eve agrees). Getting alerts would be a good pattern in case of concerns. So, apparently, our analysis seems to hold! We'd like to vet all this against the columns of the matrix. ("Consumer Data" refers to the body of commercial law.) Including the parental consent pattern would be good as well; it doesn't have to be specific to any one law/regulation. - Our presumption is that UMA is about the Resource Server Operator being a Data Controller serving the Data/Resource Subject (under some complex regime of the Data/Resource Subject's proxy, the Resource Owner, and their agent, the Authorization Server Operator). - We think we have to cover both "sharing with/delegating access to" a Data Processor (someone with limited accountability/responsibility/liability because they're getting access under your control) and another Data Controller (someone with full accountability/responsibility/liability because they're getting access on their own recognizance). We assume that AS and RS competition on interfaces for policy, resource types, etc. will need to ease paths for resource owners who interact with them. Kathleen asks: How to distinguish a license from a contract? Traditionally, a data subject isn't really given the opportunity to control what's done with their data. Eve: A license is a kind of contract/agreement, right? Mark notes that the CIS group today did a lot of great work around the FIPPS. They stress "...with the consent of the data subject". Discussion ensued about the role of the original principles, further operationalization in the DPD and then the GDPR, and the concurrent rise of the OAuth, OIDC, and UMA stack and Consent Receipts. We also discussed the Brave Browser <https://brave.com/> and their recent huge round of funding <https://techcrunch.com/2017/06/01/brave-ico-35-million-30-seconds-brendan-e…> . Kathleen provides a link to a presentation from HIMSS <http://wiki.hl7.org/index.php?title=HIMSS_2017_Patient_Choice> about VA and UMA. *AI:* Eve: Send out links to the current state of the (old) Binding Obligations and (newer) CommonAccord model clause text, which was intended to fill in PAT and RPT license text (and on and on), respectively. *AI:* Eve and Tim: Meet briefly to brainstorm what rows the PCT would have, and external experts to reach out to. *AI:* John, Mark, Kathleen: Review the X's in the cells of the matrix. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: Legal call is still on for tomorrow
by Eve Maler 08 Jun '17

08 Jun '17

We'll have a new interim chart to examine on the way to deliverable #3. Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0