August 2018 - WG-UMA - mailman.kantarainitiative.org

Draft minutes of UMA telecon 2018-08-23
by Eve Maler 23 Aug '18

23 Aug '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-23 Roll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-08-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-09>: APPROVED. Discussion about RS-based authorization flows - See thread (1 <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-HerdEt-7…> , 2 <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-2o4_QY-H…> ) There would be concern if the additional flow makes UMA2 work in a different way. In other words (as said in the chat), "we want stable UMA". Is this trying to create multiple AS's in some fashion? Actually, it's taking advantage of the conceptual availability of the RS as "its own AS", in a way, by virtue of the Adrian clause: "However, the resource server MAY apply additional authorization controls beyond those imposed by the authorization server." But maybe it's more like a PIP (policy information point) vs. *imposing* authorization controls per se, because it's passing along claims with the permission request that it gathered from the requesting party at tokenless resource request time. This suffices for a case where, as Pedro describes it, the "RS is the RO" – it's a single enterprise that runs both the AS and the RS. As an aside, UMA's lack of perfect symmetry in various ways make it somewhat more difficult to solve the corner cases we're starting to see now. - RO vs. RqP, with nothing said about the RO's AS user agent and means of proving themselves to it through authentication/claims collection: Our previous analysis showed that "decoupled" use cases (bank teller Bob needs to share with someone who is a "true" Alice) would find it useful to test Alice rigorously, in an OOB band fashion, to prove who she is. We thought of this as "backwards UMA". - AS has a means of claims collection but the RS has no means to leverage the claims collection itself: This is where Pedro's extension is starting to fill in a gap. It would be interesting if the same claims collection infrastructure is getting reused. The whole claims collection infrastructure and abstract flow, as noted in a previous meeting, looks like it could be a sort of model for a wide variety of grants. Next steps for business model and "machine-readable privacy terms" - See new deck <https://kantarainitiative.org/confluence/download/attachments/17760302/IEEE…> and info about IEEE P7012 <http://sites.ieee.org/sagroups-7012/> Andrew has been a program manager in IEEE. A "P number" (P7012) is a program number. The society it's in (SSIT) is the sponsoring organization, in this case Society for Social Implications of Technology. This group is "SSIT/SC/MachReadPrivacy". This will meet periodically as defined by the group, produce a draft, etc., as determined by the chair's abilities. Eve showed the latest status of our mappings <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…> (see callout numbers in panels) from legal party roles to technical artifacts. There are a few questions outstanding, shown in red. David described his new potential use case tied to the Personal Information Protection Company (PIPC) framework in the new Vermont law. Oliver Goodenough has indicated interest related to the insurance industry. Vermont is a well-known captive insurance market, and David anticipates that UMA could be a great ready-made solution. The law also creates a Blockchain-Based LLC (BBLLC) framework adjacent to a PIPC. Regarding data privacy and consumer protection, the goal is to come down on the side of consumer protection. If there is any additional work needing to be done, not statutory rule-making (an act passed by the legislature but other regulatory guidance around S.269), we've got some willingness there. For the captive insurance industry, a big question is: What would the "identity topology" look like that underlies the UMA authorization topology? This would determine the most friction-free and viable UMA deployment topology. For example, would an insurer-as-AS be a relying party on federated logins from their customers-as-RS's? Or is there self-insuring by large companies (or maybe single sign-on is happening anyway there?). If blockchain is being used, is blockchain identity (e.g., with Verifiable Credentials) somehow involved? Note that organizing a PIPC in Vermont doesn't disrupt an existing (or new) organization's business. Andrew asks: Would SphereIdentity or Meeco be interested in knowing about this opportunity? Thanks to Tim for spurring the initial conversation around the law! Next steps: Schedule an ad hoc meeting with the principals who may spur a demo project. Future meeting schedule We've already got *Aug 30* down as *canceled*. We also *won't meet Sep 6*, due to its being during the week of US Labor Day. However, we'll go back to a *weekly schedule starting on Sep 13*, only canceling when there aren't enough items on the agenda. New blog post If you like, feel free to publicize this post <https://www.forgerock.com/blog/why-user-managed-access-essential-creating-t…> about the Origo (financial services) UMA use case! Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Maciej 4. Eve 5. Mike Non-voting participants: - Andrew - Bjorn - Tim - David - George - Colin Regrets: - Cigdem *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

FYI, IEEE SA 7012 - Standard for Machine Readable Personal Privacy Terms
by Eve Maler 23 Aug '18

23 Aug '18

Hi WGs-- This past week at IIW a session was held (I wasn't able to attend the session itself) about an IEEE project to develop "machine readable personal privacy terms": https://standards.ieee.org/develop/project/7012.html "The purpose of the standard is to provide individuals with means to proffer their own terms respecting personal privacy, in ways that can be read, acknowledged and agreed to by machines operated by others in the networked world. In a more formal sense, the purpose of the standard is to enable individuals to operate as first parties in agreements with others--mostly companies--operating as second parties. Note that the purpose of this standard is not to address privacy policies, since these are one-sided and need no agreement. (Terms require agreement; privacy policies do not.)" This seems to have potential relevance for Consent Receipts, User Submitted Terms, UMA, and UMA Legal. Joyce Searls was the one announcing the session during agenda creation, so I managed to speak with her prior to the scheduled session, and she shared this link with me afterwards. She also said "Take a look at the write up and click through to register interest. We will be having our first formal meeting within a month or so." *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

7 9

Agenda for UMA telecon 2018-08-23
by Eve Maler 22 Aug '18

22 Aug '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-23 Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2018-08-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-09> - Discussion about RS-based authorization flows - See thread (1 <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-HerdEt-7…> , 2 <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-2o4_QY-H…> ) - Next steps for business model and "machine-readable privacy terms" - See new deck <https://kantarainitiative.org/confluence/download/attachments/17760302/IEEE…> and info about IEEE P7012 <http://sites.ieee.org/sagroups-7012/> - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Re: [WG-UMA] WG-UMA Digest, Vol 110, Issue 16
by Mike Schwartz 21 Aug '18

21 Aug '18

> From: Pedro Igor Silva <psilva(a)redhat.com> > Subject: Re: [WG-UMA] Keycloak support for UMA 2.0 > Yes, that is what I meant. One of the use cases we have is that RS may > fetch claims from external services, current HTTP request, etc, in > order to > push them along with a permission request. You are not forced to do > this > though. > Pedro, The RS can call whatever API's it wants before returning the permission ticket to the client. So this is just an optimization. IMHO, you could propose an extension, but I certainly wouldn't want to see any changes to the existing UMA specs that would hinder interoping the standard we already have. - Mike ------------------------ Michael Schwartz Gluu Founder / CEO mike(a)gluu.org https://www.linkedin.com/in/nynymike/

1 0

Re: [WG-UMA] Keycloak support for UMA 2.0
by Mike Schwartz 21 Aug '18

21 Aug '18

Way to go Pedro!!! Great news!!! The Gluu Gateway could act as the UMA RS, and we have a demo UMA client too. If you have an Internet accessible instance, we'd be interested to test that with you. Perhaps it could lead to a wider interop with WS02 and ForgeRock too (i.e. keep the RS and client constant). If you want to chat, email me off list. - Mike ------------------------ Michael Schwartz Gluu Founder / CEO mike(a)gluu.org https://www.linkedin.com/in/nynymike/

5 10

Kantara Plenary meeting right after IIW in October
by Eve Maler 15 Aug '18

15 Aug '18

Hi folks-- In case you didn't see the latest newsletter from Colin about Kantara goings-on, I wanted to flag the opportunity to attend a Kantara Plenary and Board Meeting in San Francisco (not Mountain View) the day after the next IIW concludes, on Friday October 26th. Registration is already open: https://kantarainitiative.org/pre-registration-f2f-member-plenary-board-mee… While it's looking unlikely at the moment that I can attend this one, the agenda for the plenary is shaping up to be really interesting and, I think, valuable for building cross-group deliverables. What specifically gets discussed will depend on group participant representation. (I've asked Andrew to share out that agenda...) If you think you might attend (the plenary or IIW+the plenary), feel free to drop me a note or respond in this thread. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2018-08-07
by Eve Maler 09 Aug '18

09 Aug '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-08-09 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-06-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-14> , 2018-07-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-07-12>: APPROVED by acclamation. Financial and health multi-portal use cases and solutions Deferred. News from the wider UMA world We have been hearing that WSO2 has been planning an UMA2 implementation this quarter; Eve will check in with Prabath. Eve has updated the Implementations page's Keycloak entry <https://kantarainitiative.org/confluence/display/uma/UMA+Implementations#UM…> to supply Pedro's provided information. It appears that there is an extension to the permission endpoint <https://www.keycloak.org/docs/latest/authorization_services/index.html#_ser…> to all the RS to push claims to that endpoint. "When creating tickets you can also push arbitrary claims and associate these claims with the ticket ... (example shown) ... Where these claims will be available to your policies when evaluating permissions for the resource and scope(s) associated with the permission ticket.". Is is something that would be interesting to standardize for interop? We can ask Pedro in email. He had proposed an extension (see issue 355 <https://github.com/KantaraInitiative/wg-uma/issues/355>) that would shortcut using a permission ticket at all, for narrow-ecosystem enterprise purposes. Mike is meeting with Pedro tomorrow to discuss interop testing. Mike's demo at Identiverse can be turned toward such purposes, with Keycloak as the AS. It looks like both Keycloak and ForgeRock implement just claims pushing for their claims collection flows at this point. Gluu's OXD server has a kind of UMA client middleware capability, and it would be happy with either type of claims collection. The typical assumption in pushed-claims flows these days is that Alice's AS is her IdP and also Bob's IdP, but ID token validation should properly still be "full validation", with no shortcuts. In this kind of ecosystem, obviously the AS can include itself as an additional audience alongside the client as the first audience because it knows ahead of time that it will be the one ultimately consuming it. In any "wider ecosystems" than this, that is, IdPs for Bob that *aren't* Alice's AS, tokens that get pushed by back-channel means can't be very dynamic about their audience predictions. An insight about UMA's grant structure and main options, based on the fact that a permission ticket provides a framework for allowing a variety of looping patterns of state-preserving client-to-AS-token-endpoint interaction: 1. Like the OAuth authorization code grant – useful for fairly wide ecosystems when unexpected RqPs tend to show up 1. C immediately redirects RqP to AS claims interaction endpoint 2. AS and RqP do interactive claims gathering 3. C asks for RPT at token endpoint 2. Like the SAML <https://tools.ietf.org/html/rfc7522> or JWT <https://tools.ietf.org/html/rfc7523> assertion grant profile (not just client authentication) – useful for ecosystems where AS serves as same IdP to both RO and RqP – also like ordinary SAML or OIDC SSO with login-time attribute exchange, where Bob is trying to get into some enterprise protected resource, only the resource is Alice's to protect 1. C pushes claim token (say, ID token) to token endpoint on behalf of RqP and asks for RPT 3. A hybrid flow, or if the AS didn't statically declare its claims interaction endpoint in its metadata 1. C asks for RPT at token endpoint (with or without pushing claim token) 2. AS sends need_info error with redirect_user hint 3. C redirects RqP to AS 4. AS and RqP do interactive claims gathering 5. AS redirects RqP back to C 6. C asks for RPT at token endpoint In Eve's discussion with Bertrand Carlier for his (forthcoming?) blog post, he had the insight about the authorization code flow, pointing out the analogy of the permission ticket to a "mutable authorization code" (along with noting that the PCT is very like a refresh token and the RPT is like – is! – an access token). It has been asked why we have a claims interaction endpoint, and didn't reuse the actual authorization endpoint. Mike does refer to the claims interaction endpoint as our "authorization endpoint", which is helpful rhetorically. Although it might take forensic analysis of our archives [image: (smile)], we might never have formally considered reusing the authorization endpoint directly vs. the claims interaction endpoint (former name in UMA1: requesting party claims endpoint). Our main design effort for UMA2 was inspired by the exploration in MPD (see here <https://github.com/KantaraInitiative/wg-uma/issues/154>, for example). However, note that customization would have been required anyway, and the semantics of the UMA version cover gathering of claims beyond just verification of a unique identity <https://tools.ietf.org/html/rfc6749#section-3.1>. Identiverse talks that touched on UMA: - 2018-06-27 Don’t Pave Privacy Cow Paths: Retool Consent for the New Mobility - https://www.youtube.com/watch?v=eP5U2sA6EFk - 2018-06-27 - Emerging Identity Standards in Healthcare - https://www.youtube.com/watch?v=vOypRbpn004 - Pick u2018-06-27 - UMA 2.0 Deep Dive: Applying User-Managed Access - https://www.youtube.com/watch?v=QvvJsEND30c (caption in lower third will be fixed) News from the wider OAuth and OIDC worlds One tidbit: Eve remotely attended the first OAuth WG session during the Montreal IETF 102 meeting. During this session, Justin mentioned UMA, CIBA, and the Device flow as exemplars of applying a permission ticket paradigm that could help the group develop an actual model of what a grant flow is. We should think about how we can ensure that UMA and the use cases it solves can influence the conversations going on in the OAuth and OIDC communities, and be influenced as appropriate. For example, the distributed OAuth work has parts that bear some similarity to UMA's AS discovery mechanism. It appears the CIBA spec is going to be broken up into a core and a sector-specific spec. Mike took notes on his action item to create an "UMA for decoupled/UMA-protected backchannel endpoint" swimlane. George in chat: Completely agree with engaging with IETF on the new suggestions and overlaps with UMA. Wikipedia entry(ies) in dire need of updating Deferred. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Maciej 3. Eve 4. Cigdem Non-voting participants: - George - Tim - Scott - Colin Regrets: - Andi - Thomas - Nancy - Adrian *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 5

Agenda for UMA telecon 2018-08-09
by Eve Maler 08 Aug '18

08 Aug '18

https://kantarainitiative.org/confluence/display/uma/UMA+WG+telecon+2018-08… Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes: Approve minutes of UMA telecon 2018-06-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-14> , 2018-07-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-07-12> - Financial and health multi-portal use cases and solutions - Continuing discussion from 2018-07-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-07-12> - News from the wider UMA world - News from the wider OAuth and OIDC worlds - Wikipedia entry <https://en.wikipedia.org/wiki/User-Managed_Access>(ies) in dire need of updating - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Keycloak support for UMA 2.0
by Pedro Igor Silva 07 Aug '18

07 Aug '18

Hi All, Keycloak [1] project is now supporting UMA 2.0. Except for claims gathering flow, most of the specification is implemented. The main features we support are: * Resource registration In a nutshell, the only thing we don't have yet from UMA specs is claims gathering flow. Documentation is here [1]. A simple example app (photoz) using UMA can be checked here [2]. We have extended the Protection API to include a new endpoint to manage user permissions [3]. It was a result of contributions from the community in order allow RSs to associate/manage custom policies for resources while still letting users manage them. While we don't have support for claims gathering, RSs are allowed to push claims when creating a permission ticket [4]. Will summarize those points and prepare the e-mail. Thanks. Pedro Igor [1] https://www.keycloak.org/docs/latest/authorization_ services/index.html#_service_user_managed_access [2] https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz- uma-photoz [3] https://www.keycloak.org/docs/latest/authorization_ services/index.html#_service_authorization_uma_policy_api [4] https://www.keycloak.org/docs/latest/authorization_ services/index.html#_service_protection_permission_api_papi

2 3