UMA telecon 2021-11-04

Owned by Alec Laws
Last updated: Nov 04, 2021
4 min read

UMA telecon 2021-11-04

Date and Time

Agenda

Minutes

Roll call

  • Quorum: No

Approve minutes

Deferred


The Kantara All members meeting is Dec 8th, 11-1230ET (it's virtual, link TBD)


FHIR Vulnerability Report

Working document here: Report on FHIR API Vulnerabilities 

Please take a look, all comments/contributions welcomed! There original report is attached to the confluence page 


OAuth vs UMA content

previous discussion: UMA telecon 2021-09-16

Who is the right audience for this content? a version at different 'levels'? Show value to Business & Technical separately, 


At biz level, there is buy into 'OAuth is awesome' and creates the question "so why do I need UMA?"

  • 'putting you lock on the wrong locker' UMA helps prevent this mistake
  • you can apply Oauth to protect an API, however the solution still needs to consider who's who (authN) and who has access to what (authZ)

Maybe it's 'what's oauth' and then a 'what's UMA to follow up'

Here' the problem UMA addresses: it allows a person to control their stuff, and how they want to share it with somewhere else. OAuth is an underlying technology to authorize the requestor. eg give Alice the ability to call the help desk to give her Mom or spouse access to her record. UMA gives Alice the ability to do this herself. THe cost reduction of self-service access is similar to removing manual 'forgot password' flow.

By using UMA, it reduces the custom development of these features in existing stacks. UMA services come with these features off the shelf, shift custom impl to configuration. (Except policy which is... left to the reader)

Removes requirements from the enterprise by given the user the direct ability to manage their stuff themselves. 

Google drive sharing is the best practical example of this (even though it doens't use UMA (sad)). 


What is the best format for this content? 

  • 2-3 slides that members can easily re-use



What about UMA vs GNAP? Will GNAP replace OAuth and UMA? 

Have never heard a customer request GNAP, only discussion within the IETF/OAuth/UMA communities. 

Check out the recent GNAP progress here: https://github.com/ietf-wg-gnap/gnap-core-protocol

Is there a clear UMA → GNAP transition?



PAT lifecycle management

PAT lifecycle management, it is a OAuth access token, with expiration and refresh token

When it's needed (eg when a client makes a request) it can be expired

How long should it live? 

  • the PAT itself it an access token and should expire in a short window (eg normal access token, such as 5mins)
  • the refresh token can have a loooong lifetime, eg months/years
  • the PAT represents the ROs authorization for the RS to trust the AS, and for the AS to protect the RS's API
    • it should expire aligned with that human level policy around expiration

What to do if the PAT and it's refresh have expired? Need the RO to come back and regenerate it

  • should there be a different message to the client? It's not the RO at the client, instead it's the RqP. We shouldn't expose the maintenence of the PAT to the RqP
  • the RS can't issue a ticket to the RqP
  • there is no definied response in this case, is it a 403? there is no appropriate www-authenticate type redirect
  • UMA Implementer's Guide#pat-invalidResourceServerErrorHandlingWhenthePATIsInvalid 
    • return a 403 with http error and header 'Warning: 199 - "UMA Authorization Server Unreachable"'
  • ideally there is some RS → RO notification to renew


Depends on the RO model. When the RO is the RS, the RS can always get a new PAT using it's client credentails

If the RO is a proper subject, then these challenges all exist

Could the AS always allow a RS=RO PAT, how would this interact/intersect with proper subject RO bounded PATs? 


A not-uma solution (relationship manager solution)

RS <> AS: resources registered (eg /patient)

RS → RO: 'id token' with the subject id (alec123)

RO → AS: the RS knows me as alec123, I want to give Bob access to /patient for that subject

AS → RS: introspection result returns resource and subject id



AOB

  • We are planning a 3 hour working session on December 9th, we will use extend the normal call from 930-1230ET 
    • Want to make progress on some of the in-progress docs, have them in a consistent state 
    • Eve, Nancy, Alec, Andi 
    • If you're up to attend, please email Alec, or leave a comment on these minutes



Next week, Steve will give a de-brief of the FIDO authenticate conference



Topic Candidates (from previous week's telcon)

  • Delegation and Guardianship

  • Outcome of user stories discussion

  • PDP architecture includes the concept of governance registry/discovery

  • TOIP/SSI are starting to define this ecosystem function

  • ANCR records update

  • Privacy as Expected/ANCR update : 2/3 weeks out (Sal?)


Attendees

As of October 26, 2020, quorum is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)

Voting:

  1. Sal
  2. Alec
  3. Domenico
  4. Steve

Non-voting participants:

  1. Scott

Regrets:

  1. Nancy
  2. Eve