https://kantara.atlassian.net/wiki/spaces/uma/pages/45875201/UMA+telecon+20…
UMA telecon 2022-08-25Date and Time
- Primary-week Thursdays 06:30am PT; Secondary-week Thursdays 10:00am PT
- Screenshare and dial-in:
https://zoom.us/j/99487814311?pwd=dTAvZi9uN0ZmeXJReWRrc1Zycm5KZz09
-
United States: +1 (224) 501-3316, Access Code: 485-071-053
- See UMA calendar for additional details:
http://kantarainitiative.org/confluence/display/uma/Calendar
Agenda
- Approve minutes since UMA telecon 2022-06-30
<https://kantara.atlassian.net/wiki/spaces/uma/pages/14352423/UMA+telecon+20…>
- UDAP Spec Reviews/ Next Steps
- Determine next work items
- AOB
Attendees
- NOTE: As of October 26, 2020, quorum
<http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)
- Voting:
- Alec
- Peter
- Steve
- Non-voting participants:
- Lenore
- Nancy
- Regrets:
Quorum: No
Meeting Minutes
Approve previous meeting minutes
- Approve minutes of UMA telecon 2022-08-11
<https://kantara.atlassian.net/wiki/spaces/uma/pages/39124993/UMA+telecon+20…>
- Deferred - no quorum
TopicsUDAP Spec Reviews
- We need to come to their groups to advocate for UMA
- HL7 FAST Infrastructure Group:
https://confluence.hl7.org/pages/viewpage.action?pageId=134938778 <<<
this is the one folks should attend
- There is an upcoming connect-a-thon (in person ONLY, registration
is open):
https://confluence.hl7.org/display/FAST/FAST+-+HL7+FHIR+Connectathon+-+Sept…
One of our questions around UDAP is that it's not an implementation
profile, HL7 has created IGs that use UDAP as the base profile here:
https://build.fhir.org/ig/HL7/fhir-udap-security-ig/branches/main/user.html
Determine next work items
What do we want to do next? Lots of ideas below, what's most important
Current WIP
- Update Julie Report to v0.4 – Nancy to accept suggested changed,
reviewed with group ~1month ago
- New report with core UMA (no use-case) content from Julie Report →
could evolve to IDPro article? – Alec
- UMA Glossary – Steve
- Confluence Clean Up: activate new links + archive old content +
general usability of the wiki – Alec / Steve,
We prioritized the list below, lower numbers = higher priority. Nothing is
"final", feel free to comment
- one driver is if the item was of interest to many or few member
- other consideration is who is motivated to lead the item
AOB
Potential Future Work Items / Meeting Topics
- 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
- 20 Confluence clean up, archive old items and promote the latest &
greatest
- 10 UMA glossary – Steve has started
- 600 Review of the email-poc correlated authorization specification
- https://github.com/umalabs/correlated-authorization
-
https://groups.google.com/g/kantara-initiative-uma-wg/c/BntTknCOAAE/m/EzL9i…
-
https://groups.google.com/g/kantara-initiative-uma-wg/c/ablVJ9cAreg/m/a_ZpC…
- 120 A financial use-case report (following the Julie healthcare
template)
- either open banking or pensions dashboard
- openbanking is to FHIR(data model) as FAPI is to SMARTonFHIR(authZ
protocol profile)
- Who would lead this/ needs this for UMA in open banking contexts?
Should come after FAPI review?
- 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?
- 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?
- 170 UMA + Verifiable 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
- IDPro knowledge base articles
- UMA 2 playground/sandbox
- eg https://developers.google.com/oauthplayground/,
https://www.oauth.com/playground/
- 150 Minor profiling work,
- resource scopes → scopes
- PAR as dynamic scopes eg fhir query params
- 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
https://kantara.atlassian.net/wiki/spaces/uma/pages/33751041/UMA+telecon+20…
UMA telecon 2022-08-04Date and Time
- Primary-week Thursdays 06:30am PT; Secondary-week Thursdays 10:00am PT
- Screenshare and dial-in:
https://zoom.us/j/99487814311?pwd=dTAvZi9uN0ZmeXJReWRrc1Zycm5KZz09
-
United States: +1 (224) 501-3316, Access Code: 485-071-053
- See UMA calendar for additional details:
http://kantarainitiative.org/confluence/display/uma/Calendar
Agenda
- Approve minutes since UMA telecon 2022-06-30
<https://kantara.atlassian.net/wiki/spaces/uma/pages/14352423/UMA+telecon+20…>
- UDAP Spec Reviews - tiered oauth
- Charter Refresh - vote if quorum
- Home Page Refresh - review/publish draft!?
- AOB
Attendees
- NOTE: As of October 26, 2020, quorum
<http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)
- Voting:
- Sal
- Steve
- Alec
- Non-voting participants:
- Chris
- Regrets:
Quorum: No
Meeting Minutes
Approve previous meeting minutes
- Approve minutes of UMA telecon 2022-06-30
<https://kantara.atlassian.net/wiki/spaces/uma/pages/14352423/UMA+telecon+20…>
, UMA telecon 2022-07-07
<https://kantara.atlassian.net/wiki/spaces/uma/pages/17891329/UMA+telecon+20…>
, UMA telecon 2022-07-14
<https://kantara.atlassian.net/wiki/spaces/uma/pages/21299201/UMA+telecon+20…>
, UMA telecon 2022-07-21
<https://kantara.atlassian.net/wiki/spaces/uma/pages/24510465/UMA+telecon+20…>
, UMA telecon 2022-07-28
<https://kantara.atlassian.net/wiki/spaces/uma/pages/28180481/UMA+telecon+20…>
- Deferred - no Quorum
Topics
UDAP Spec Reviews - tiered oauth
https://www.udap.org/udap-user-auth.html
Background, the UDAP profiles are in consideration to be recommends for use
in US Health care. A few groups have/are running connect-a-thons testing
their use (hl7:
https://confluence.hl7.org/pages/viewpage.action?pageId=90362084, carin?)
https://groups.google.com/g/udap-discuss
## purpose:
"This distributed framework allows the reuse of existing user credentials
and improves security by providing user data directly to the Resource
Holder rather than passing it through a third party such as a client
application."
"providing user data directly to the Resource Holder rather than passing it
through a third party such as a client application."
- eg the AS gets claims directly instead of through the client app
## how to use:
Use of this extension is requested by Client Apps and Resource Holders by
including the “udap” scope in their requests to the upstream authorization
endpoint.
## Q&A & Comments
resource holder? is the RS + AS
what does this mean for the SW client developer perspective? add 'udap' as
scopes to requests?
we already use certs to enable TLS. there is mTLS as server-server
authentication, however this pulls the certs up into the OAuth protocol
layer. This allows additional requirements about what certs must
contain/convey to other parties beyond key material
Are certs only being used to establish trust between services? If so, why
does this need to make changes at the protocol layer?
Can these profiles be prepared without the need for the 'udap' params? If
the main idea is certificate based endorsements and trust policies, why
does it need to get to the protocol level?
Can they include more contextual specificity, eg what are the allowed acr
values, how will cert based policy decisions work? Implementations need to
define another layer of profile/ implementation guide to make this useful,
the HL FAST group has more specific use-case based IGs:
https://www.udap.org/udap-ig-consumer-facing-health-appshttps://www.udap.org/udap-ig-b2b-health-apps
It's already fairly normal for IDPs to federate to other downstream IDPS eg
a standard feature of most IDP products?
if UDAP becomes federally mandated in US Health care who owns the IP for
the protocols/profiles? will be open or contributed to a standards body (eg
IETF?) Would be great to see this open to comments in a public non-profit
space
How does this relate to user managed access aka patient directed exchange?
The trust between services is still based on the trust policies of the
operators and the certificates they can present
https://groups.google.com/g/udap-discuss
## how it works
summary: client requests authZ with a idp_uri, the AS federates to that idp
for user authN
1
GET resource_holder_uri/.well-known/udap
{
"x5c" : ["{cert1}", "{cert2}", …]
}
- to check if they trust this RH(AS)?
- equivalent to a jwks endpoint?
- why does UDAP *mandate* certificates?
2
GET /authorize?
... normal oauth/oidc params ...
*scope=udap*+ other scopes&
*idp=https://idp.example.com/optionalpath&
<https://idp.example.com/optionalpath&>*
3
3.1 is the requested idp trusted?
- "retrieving the IdP’s UDAP metadata from
https://idp.example.com/optionalpath/.well-known/udap
- *evaluating the IdP’s certificate against the Resource Holder’s local
trust policies.*"
3.2 if nessecary, RH(AS) does DCR with the upstream IDP
3.3 if a and/or fail, the RH(AS) may present list of other idps
- if can't agree on idp, return new(?) error code `invalid_idp`
3.4 the RS(AS) acts as an OIDC client to the upstream idp (redirect to
/authorize + includes the 'udap' scope)
4 normal OIDC
except: the token requests includes an param `udap=1`
required idtoken claims (mostly normal, requires acr/amr)
iss: IdP’s unique identifying URI (matches idp parameter from Step 2)
sub: unique identifier for user in namespace of issuer, i.e. iss + sub is
globally unique
aud: client_id of Resource Holder (matches client_id in Resource Holder
request in Step 3.4)
exp: expire time (should be short-lived)
iat: issued at time
auth_time: time that user last authenticated (optional)
nonce: when included in Resource Holder’s request, must match nonce value
from Step 3.4
acr: http://udap.org/[ial1-3|loa1-4]
amr: http://udap.org/[aal1-3|loa1-4]
"If the subject identifier included in the ID token has not been previously
mapped to a local user or role" the RH may request the userinfo
- Q. otherwise it can't request the info?
RH completes the oauth flow with the client app (callback with code)
## Comparison with UMA Grant:
3.3.2
"The client redirects an end-user requesting party to the authorization
server's claims interaction endpoint for one or more interactive
claims-gathering processes as the authorization server requires. These can
include direct interactions, such as account registration and
authentication local to the authorization server as an identity provider,
filling out a questionnaire, or asking the user to authorize subsequent
collection of claims by interaction or pushing, and persistent storage of
such claims (for example, as associated with a PCT). *Interactions could
also involve further redirection, for example, for federated (such as
social) authentication at a remote identity provider*, and other federated
claims gathering. See Section 5.7 and Section 6.2 for security and privacy
considerations regarding pushing and persistence of claims."
eg you can federate to other idps
UMA ASs can support the udap params + metadata
## Comparison with OIDC:
3.1.2.1. Authentication Request
login_hint / id_token_hint, closest mechanism? "Hint to the Authorization
Server about the login identifier the End-User might use to log in (if
necessary). This hint can be used by an RP if it first asks the End-User
for their e-mail address (or other identifier) and then wants to pass that
value as a hint to the discovered authorization service. It is RECOMMENDED
that the hint value match the value used for discovery. This value MAY also
be a phone number in the format specified for the phone_number Claim. *The
use of this parameter is left to the OP's discretion.*"
eg it can be a previous sub, or an email (which implies an authN domain),
or up to the OPs discretion (eg could be an idp uri)
Charter Refresh
Draft Charter 2022
<https://kantara.atlassian.net/wiki/spaces/uma/pages/4850242/Draft+Charter+2…>
Home Page Refresh
UMA WG: User Managed Access (DRAFT)
<https://kantara.atlassian.net/wiki/spaces/uma/pages/4850191>
Alec will move the draft in place as the new homepage later today!
Julie Use Case - review updates
https://docs.google.com/document/d/1aG88GJMxOdYoEjQIAyzoTrUnFud-cnpmPD1rt9X…
AOB
- next week will discuss another UDAP spec
