UMA telecon 2022-08-04

Owned by Alec Laws
Last updated: Aug 04, 2022

UMA telecon 2022-08-04

Date and Time

Agenda

  • Approve minutes since UMA telecon 2022-06-30
  • 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 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

  • 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-apps https://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&

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


Home Page Refresh

UMA WG: User Managed Access (DRAFT)

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-cnpmPD1rt9XAdGA/edit 



AOB

  • next week will discuss another UDAP spec



Potential Future Work Items / Meeting Topics

  • FAPI Review (FAPI + UMA)
  • Confluence clean up, archive old items and promote the latest & greatest
  • Review of the email-poc correlated authorization specification
  • 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)
  • mDL + UMA
  • 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?
  • IDPro knowledge base articles
  • UMA 2 playground/sandbox
  • Minor profiling work,
    • resource scopes → scopes 
    • consent as claims (needs_info)
    • PAR as dynamic scopes eg fhir query params
    • claims profiling (beyond IDTokens): VCs, consent, policy

Upcoming Conferences