- WG-UMA - mailman.kantarainitiative.org

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

Sorry for lack of agenda today — shall we meet?
by Eve Maler 26 Jul '18

26 Jul '18

I’ve been (and am still) on the road, but I do have time for the call. Apologies for my absent-mindedness. Do we have sufficient items to suggest that meeting today would be productive? Please send them in. I will make the decision an hour ahead and send a note here and on Skype. Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 1

Article: "Why protecting privacy is a losing game today—and how to change the game"
by Thomas Hardjono 20 Jul '18

20 Jul '18

Dear UMAnitarians, You might find this article interesting: "Why protecting privacy is a losing game today—and how to change the game". https://www.brookings.edu/research/why-protecting-privacy-is-a-losing-game-… Best -- thomas --

5 6

W3C Workshop on Permissions and User Consent Sep 18-19 in San Diego
by Eve Maler 17 Jul '18

17 Jul '18

https://www.w3.org/Privacy/permissions-ws-2018/cfp.html Note that there's also Consumer Identity World Sep 19-21 in Seattle. (I'll be speaking there in the Kantara workshop session.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2018-07-12
by Eve Maler 12 Jul '18

12 Jul '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-07-12 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>: Deferred. Vermont's new law David worked on Vermont's new S.269 <https://legislature.vermont.gov/assets/Documents/2018/Docs/ACTS/ACT205/ACT2…> ensconcing Personal Information Protection Companies (PIPC) (see the news <http://www.gravelshea.com/wp-content/uploads/2018/06/Blockchain-Terrain.pdf>). The law sets up a basic framework for PIPCs, but there is a lot of room for the specifics. Tim had a role in the work as well. Sec. 5 in the law calls for a FinTech Summit to be held, and the Department of Financial Regulation to take further steps. There could be appetite for learning how UMA can provide value in separating "personal information" services from "protection" services. Thomas served as a moderator at the DC blockchain caucus. The blockchain startup CEOs mentioned Vermont as leading in the area of "blockchain sandboxes", but being blocked at the federal level. Propy is a new company in Vermont doing <https://blog.propy.com/propy-announces-first-us-pilot-with-vermont-23ec0b2d…> land registry/real estate recording. Because of the US blockages, the first POC was in Ukraine. What about UMA with and/or vs. DIDs? Eve's recent answer when asked: "I know of a couple of projects that combine them, and I consider them complementary. UMA has long had a design principle about being “ID-agnostic” (see the Charter <https://kantarainitiative.org/confluence/display/uma/Charter>) and it seems to work. Also, the actual consent, permissioning, and access control mechanisms built into SSI-type systems, as far as I can see, aren’t directly related to their blockchain tech but are part of the rest of their app stack. So they [the consent/permissioning/access control mechanism] could be proprietary, OAuth/UMA-based, etc." More specifically, UMA has several places where identifier/claim sources come into play: How a RO identifies themselves to the RS, how a RO identifies themselves to the AS, how the AS gathers claims from the RqP interactively, and how the client conveys a claim token to the AS token endpoint. Mike notes that a DID is a reference to what UMA calls a claim token and, we think, doesn't specify a format. The BSC DG report <https://kantarainitiative.org/file-downloads/report-from-the-blockchain-and…> has a figure illustrating the role of blockchain tech (potentially necessary, but always insufficient) in an app stack. Leadership team elections The current leadership team roster is here <https://kantarainitiative.org/confluence/display/uma/Leadership+Team>. *MOTION:* Sal moves: Eve to serve as chair for another annual term and Maciej to serve as vice-chair for another annual term. APPROVED by unanimous consent. New issue 361 Next time we open up the specs, we'll take a look at this. Discuss/compare financial and health "multi-portal problem" use cases - Discuss/compare HEART <http://openid.net/wg/heart/> use case Alice Shares Clinical Records With Her Spouse <http://openid.net/wordpress-content/uploads/2018/07/AliceSharesClinicalReco…> and Origo use case (see their architecture <https://www.origo.com/news/PensionsDashboardArchitecture.aspx> description, adoption <https://www.origo.com/news/Bringing_Pension_Industry_On_Board_Pensions_Dash…> recommendations, and performance testing <https://www.origo.com/news/Pensions_Dashboard_Scalability_Release.aspx> news) for cross-sector implications of the "multi-portal problem" - May relate to issues 53 <https://github.com/KantaraInitiative/wg-uma/issues/53> (Assess interest in making AM a formal client of APIs for policy servers, interaction services, etc.) and 106 <https://github.com/KantaraInitiative/wg-uma/issues/106> (Have an API to let an RS register the user’s sharing preferences/policies directly) Maybe new UMA infrastructure (Eve had been imagining that you need a formal policy API and a "consent API access token" or CAT!) isn't strictly necessary, at least for now. Looking at the Origo solution (see the two-part UK Pensions Dashboard scenario in the "Legal role definitions <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…>" slides), its Pensions Dashboard service is the unique client app that then presents a policy-setting service to the RO. It needs the two-step approach that Origo uses, but it works for then sharing with RqPs who aren't equal to Alice, and for centralized policy setting with a client where the business climate (as in US healthcare today) wouldn't be friendly to each AS not working with competitor RS's running policy interfaces. This solution may be a common design pattern. AI: Eve: Intro Nancy and David in email to pursue the topic further prior to the next call (which is *July 26*). Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Sal 2. Maciej 3. Eve 4. Mike Non-voting participants: - Thomas - Nancy - Bjorn - David Thelander - lawyer - licensed in Vermont, SEC background, Gravel & Shea, blockchain and identity trust companies Regrets: - Domenico *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0