...
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 minutes of UMA telecon 2023-07-13 , UMA telecon 2023-08-10 , UMA telecon 2023-08-24 , UMA telecon 2023-09-07
Deferred - no quorum
Topics
...
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?
information for the WG. Peter will come back with refreshed reading of -7
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
...