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
