- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2018-11-15
by Eve Maler 14 Nov '18

14 Nov '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-15 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-11-08 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-08> - Discuss UMA2/IETF practicalities - Thoughts on inputs to resource-indicators <https://tools.ietf.org/wg/oauth/draft-ietf-oauth-resource-indicators/> , oauth-distributed <https://tools.ietf.org/wg/oauth/draft-ietf-oauth-distributed/>, etc. - Discuss extensions existing/desired - 180 degrees / decoupled use case - Use case doc <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/Vk3YpypIL…> - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

A relevant IETF draft - Resource Indicators for OAuth 2.0 draft-ietf-oauth-resource-indicators-01
by Cigdem Sengul 13 Nov '18

13 Nov '18

Hello, This may be of interest to us too: Resource Indicators for OAuth 2.0 draft-ietf-oauth-resource-indicators-01 Several years of deployment and implementation experience with The OAuth 2.0 Authorization Framework [RFC6749<https://tools.ietf.org/html/rfc6749>] has uncovered a need, in some circumstances, for the client to explicitly signal to the authorization server where it intends to use the access token it is requesting. Thanks, --Cigdem

1 0

Draft minutes of UMA telecon 2018-11-08
by Eve Maler 09 Nov '18

09 Nov '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-08 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2018-10-18 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18> and UMA telecon 2018-11-02 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-02> APPROVED. Discuss extensions added to implementations or desired in more depth Slide 2: Alec presented on what Identos is doing to profile and extend UMA. They are presenting an UMA-standard interface to clients while maintaining RO privacy. They made most changes on the RO side. The stuff in blue is their additions. The biggest privacy challenge was the AS's ability to correlate transactions/interactions. The biggest change is the addition of the Agent role. The Agent is permitted to maintain secrets and private information. They're working with the University of Ottawa. Client requests are all delegated to the Agent. The moved the RS relationship to the Agent from the AS. The client can get resources from many different RS's. The last change has to do with being an IdP ( ? ), since the AS is decoupled. Slide 3 (Demo 1): Registration to Health Network. This is a test with the Ministry of Health in Ontario. The AS is the Ontario Health Network. Niagara Health is a hospital in Ontario that has a relationship with the RO. (We viewed the createID.mov demo video, showing the steps on the slide.) Slide 4 (Demo 2): This follows the UMA flow as far as the client is concerned, except that it skips the permission ticket request and goes directly to claims gathering (step 1a). (We viewed ton-demo.mov.) The claim the RqP is using is a FIDO-authenticated. PATs don't really look the same because it's between the RS and Agent. Scopes are predefined so the client goes to the AS first and asks for the scopes it's preconfigured to ask for. The "federated authorization" piece has been sort of replaced. The client starts by presenting a "capability ticket" rather than a variable-meaning "permission ticket". The PAT sort of, analoguously, "moves to" the client side. This is what the blue "P" means on slide 2. There is "RS discovery" instead of AS discovery. There is still a previous relationship with RS's. Immunization records, for example, might come from one or another source. The RO can say which RS should be used to fulfill a request. They have been looking at there being multiple AS's in the environment, potentially in a cross-border use case. The Agent role could involve SSI ("wallet" apps) with consensus-based trust with different AS's. So far SSI is an option that they're investigating. They have a draft extension spec that they've been working on for 1.5 years. Sharing that would be welcome, as that helps interop. With lots of startups out there going so fast, it was noted, consumers and security can suffer without documenting a pattern being used. They are wrapping their project with Ontario around the end of this month and think they can share their draft after that. IETF and the UMA specs Eve forwarded a link to discussion about AS discovery mechanisms on the OAuth list that is UMA-relevant. IETF is generally mostly F2F-friendly and has three (really big) meetings a year. March 2019 is in Prague and July 2019 is in Montreal. Thomas speaks up about attending Europe and North America meetings to advocate for UMA design patterns and themes. Adrian and Eve as well. Nancy speaks in favor of getting UMA better understood in the FHIR community. There is a FHIR event in Amsterdam next week. 180 degrees use case / decoupled use case discussion tbs Attendees As of 18 Oct 2018, quorum is 5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Peter 4. Maciej 5. Eve 6. Cigdem Non-voting participants: - Adrian - Alec - Nancy - David - Scott - Thomas - Colin Regrets: - Tim - George - Mike by reason of tubas - Andi by reason of sound systems *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

For potential discussion today
by Eve Maler 08 Nov '18

08 Nov '18

A representative portion of an email thread about distributed-oauth on the OAuth list: https://www.ietf.org/mail-archive/web/oauth/current/msg18489.html So, for discussion today: What's the most effective way to get the various UMA design elements considered? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2018-11-08
by Eve Maler 07 Nov '18

07 Nov '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-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 of UMA telecon 2018-10-18 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18> and UMA telecon 2018-11-02 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-02> - Discuss extensions added to implementations or desired in more depth - Alec to discuss Identos extensions/ideas - 180 degrees use case / decoupled use case discussion - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2018-11-02
by Eve Maler 02 Nov '18

02 Nov '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-02 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2018-10-18 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18> Deferred. Discuss extensions added to implementations or desired in more depth Pushing claims from the RS to the AS during the permission request: Keycloak does this <https://www.keycloak.org/docs/latest/authorization_services/index.html#_ser…> (using the actual UMA claim_token parameter). The use case is for when the "RS is the RO". The Keycloak likes the UMA permission ticket model because it "separates the RS from the client" and enables a human user to set sharing preferences, so this is why Pedro calls it "not the typical UMA use case". What does the RS know that the client can't provide? What is an example of the claims it passes? The RS might want to send the company that the user belongs to, or any run-time information related to the current request for the resource. A classic example: If the client is talking to the RS via MTLS, you can send the CLN of the client cert or the cert itself. Then you can ensure the permission ticket is given only to the client that deserves it. The RS can push any information to the AS for evaluation that could free the RS from doing that job. In the past, we've also talked about the client's apparent IP address when it shows up at the RS; this is one input signal that the RS could convey to the AS as part of eventual policy evaluation, which could be combined with a similar signal that the AS could detect when the (same?) client shows up at the token endpoint. The source of claims could be anything. Keycloak provides a Claims Information Point <https://www.keycloak.org/docs/latest/authorization_services/index.html#_enf…> that could serve as a source. The client isn't allowed to push claims to the RS at the point of requesting a resource, though of course whatever was part of the API call the client made could be used by the RS as "fodder" in pushing information ("claims") to the AS in the permission request. Another use case could be for when you need a specific fine-grained value constraint, akin to what Open Banking needs in order to arrange for a payment of exactly 60 pounds (rather than enabling authorization of "payment scope" generically for some app). If you're stuck using only the OpenID Connect spec as already written, then this is why OB hunted around and leveraged the request object. Peter notes that fine-grained authorization (scopes?) would be of interest. The primary use case is a document (may not be verified by third parties) for which temporary access needs to be granted to third parties. Customs/border control needs access for a span one hour prior ↔ one hour after my arrival. This is the "expiring entitlements" use case. They're using consent receipts in a manner not originally intended, involving negotiation. He's engaging with the CIS WG on this, such that the receipts can reflect the resource owner is the offerer of access. See this blog post <https://idimmusings.com/2018/10/31/kantara-initiative-work-groups-on-data-s…> and this mind map <https://share.mindmanager.com/#publish/Dy37bDd3dLe-sNUuxjHMDffKegAzJCB9wByD…>. (The two WGs were hoping to do joint work on this – maybe we can get back to that in 2019. The UMA business model should be able to support this.) Pedro notes that Keycloak supports claim tokens that are ID tokens, and also bearer access tokens. The HIE of One/Trustee implementation supports uPort claim tokens. It seems there is some support for bringing some of these topics to IETF, which means engaging in a more sustained way there. Let's discuss more next time. 180 degrees use case / decoupled use case discussion Deferred. Attendees As of 18 Oct 2018, quorum is 5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Peter 3. Sal 4. Andi 5. Maciej 6. Eve 7. Mike Non-voting participants: - Alec - George - Nancy - Pedro - Thomas - Colin - Bjorn Regrets: - Cigdem *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

A reminder: we meet tomorrow, not today
by Eve Maler 01 Nov '18

01 Nov '18

Agenda coming (sorry about the delay — I’m on the road — but dial-in info is the same as usual, as listed on our home page and calendar). We’ll discuss the various extensions and extension desiderata being seen in implementations. Eve Maler (sent from my iPad) | cell +1 425 345 6756

2 2

Agenda for UMA telecon 2018-11-02 (Friday meeting!) (we are in "summertime skew"!)
by Eve Maler 01 Nov '18

01 Nov '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-02 *NOTE:* The EU has changed clocks but US hasn't! So this time will be "off" if you are in the UK or Europe but "normal" if you are in the US. I'm sorry about that. Please check the calendar link if you are in any doubt. Date and Time - *Thursdays 9am PT – special day this week FRIDAY (same time as usual)* - 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-10-18 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18> - Discuss extensions added to implementations or desired in more depth - Discuss Keycloak extension re claims added to permission request with Pedro - 180 degrees use case / decoupled use case discussion - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

"180 degrees" use cases
by Eve Maler 24 Oct '18

24 Oct '18

Nancy shared with me her "180 degrees" use cases writeup for distribution; it's attached. This connects to our discussion of last week <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18> . (Just a reminder that we're not meeting tomorrow because of IIW, and that our meeting next week, normally scheduled for Thursday, has been shifted <https://kantarainitiative.org/confluence/display/uma/Calendar> to Friday Nov 2. If anyone wants to be added to the calendar invite on a one-time or ongoing basis, or to the Skype chat group, let me know.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New article from Justin on post-OAuth2
by Eve Maler 24 Oct '18

24 Oct '18

https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade This is an important read. Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

2 2