UMA telecon 2023-09-21

UMA telecon 2023-09-21

Date and Time

Agenda

Attendees

  • NOTE: As of Sept 15, 2022, quorum is 3 of 5. (Peter, Sal, Alec, Eve, Steve)

  • Voting:

    • Alec

    • Peter

  • Non-voting participants:

    • Hanfei

    • Nancy

    • Chris O

  • Regrets:

    •  

Quorum: No

 

Meeting Minutes

Approve previous meeting minutes

Topics

 

Pensions Dashboard Use-case report

Draft will be worked on here: Pension Dashboard Use-Case Report

 

Discuss: UMA presentation for HL7 FAST WG

Nancy reached out to some members of the HL7 FAST community, they are interested in joining one our upcoming calls to hearing an ‘intro to UMA’ type presentation

  • “UMA is complementary to what you’re working on”

  •  

  • What does OAuth 2 specify, and what UMA 2 adds on top → additional features added

  • How is UMA specified, Grant & Fedz

  • Use-case, showing where Oauth2 falls short (many single AS/RS pairs)

    • managing fine grained access, scopes → enforcement, including sensitive data filtering

    • knowing what resources a FHIR RS has, the difference to HL7 capability statements(?)

    • patient included in the management of their information. Very difficult today since has to admin many places? patient ID/interfaces?

      • taking consent and turning into policy, “computable consent” concept,

  • What are the problems UDAP/FAST are trying to address?

    • patient matching

    • UDAP (client security, trusted federated registration, federated identity)

 

 

UMA and Wallets/User Held Credentials (+ mDL?)

  • how does a wallet fulfill both an RS and AS responsibility for a user? How are available resources and attributes understandable by a wide-ecosystem

  • how does a local/offline wallet act as an RS if it’s offline?

  •  

mDL spec -5 and -7 introduce the OPENID vocabulary, where the UMA 2 concepts could fit

  • online mode: access tokens come from a mobile device to the RP(‘verifier') who then go hit an online AS to get a new access token used to access RS endpoints (e.g. identity or data resources)

    • online AS is tied to the wallet, e.g the wallet points the RP to only one AS

    • EU wallets allow other attestations to be issued into the wallet

    • online cases include OAuth-like access: use an access token to hit an RS API

  • offline mode: the device/wallet is the AS (&RS?). the RP makes a request for a set of claims (or “zkps” implemented as ageover_X claims, kv-pairs, including optional/requests) (against an extensible mDL schema),

    • wallet itself is a ‘delegated rs', the claims it holds are signed by the issuer (not json, using cbor)

    • offline cases dependant on OIDC: the claims are transmitted in a token response (similar to ID Token with claims) vs requiring many ‘API calls’

When the AS and RS are co-located, especially directly under users control, UMA is not needed

 

  • how to create true user-controlled ecosystem, not a few major wallets… or separate wallets for each credential…

issuer → holder RS → RP

 

UMA fits into the ‘online mode’ where the openid binding happens. If a wallet is issued data from many issuers, who each host an RS, the wallets AS is protected access to many federated RSs (UMA)

Alternatively, the wallet doesn't need to be tied to a single AS, instead could issue resource locations to the RP, and the RP follows UMA Grant to get appropriate access tokens

 

What is our Goal in this area?

  1. information for the WG. Peter will come back with refreshed reading of -7

  2. impl guide to work with UMA ASs or use UMA to solve their federated RS flows

Next steps: think about what work products we may want to produce

 

AOB

 

Potential Future Work Items / Meeting Topics

 

Tentative 2023 roadmap:

 

Full list:

  • 20 Confluence clean up, archive old items and promote the latest & greatest

    • 10 UMA glossary – Steve has started 

  • 100 FAPI Review (FAPI + UMA) 

    • scope: how the FAPI work could be applied to UMA ecosystems

    • review may inform what profiling work is required, eg if UMA must support PAR to work with FAPI

  • 120 A financial use-case report (following the Julie healthcare template)

    • openbanking is to FHIR(data model) as FAPI is to SMARTonFHIR(authZ protocol profile)

    • 123 Pensions Dasboard Report → use-case is well understood and live/going live soon. tight use-case

    • 127 Open Banking Report → requires more research, determine use case

      • Who would lead this/ needs this for UMA in open banking contexts? Should come after FAPI review?

  • 130 IDPro knowledge base articles

  • 140 Wikipedia article refresh

  • 150 Minor profiling work,

    • resource scopes → scopes 

    • PAR as dynamic scopes eg fhir query params

    • policy manager & policy description

    • 110 pushed claims types: templates + profiles (beyond IDTokens): 171 VCs, 113 consent, policy, mDL

      • use-case, consent as claims (needs_info),

        • if the client has gathered RqP consent, can it be presented to the AS

        • the policy to access a resource says "you must have agreed to this TOS/consent"

        • compare to interactive claims gathering where the AS would present this consent/TOS to the RqP

        • intersection with ANCR/consent receipt/trust registry work in other Kantara groups

  • 170 UMA + Verifiable Credentials OR UMA and Wallets/User Held Credentials

    • how would VCs work in an UMA ecosystem? How could VCs be used as claims in UMA

    • There are openapi specs for VC formats

    • Could UMA protect a VC presentation or issuance endpoint?

    • There's a lot of openid4vc profiles 

  • 300 mDL + UMA

    • scope: how mDL could work in UMA ecosystems, how mDL could be a claim to UMA 

    • is there a role for UMA in token fabrication and referencing it as the RS?

  • 600 Review of the email-poc correlated authorization specification

  • 500 UMA + GNAP https://oauth.xyz/specs/ 

    • would we have an UMA GNAP version (eg extension of GNAP or UMA? UMAonGNAP) 

    • will GNAP meet all the UMA outcomes?

  • UMA 2 playground/sandbox

Upcoming Conferences

  •