UMA telecon 2022-09-29

UMA telecon 2022-09-29

Date and Time

Agenda

  • Approve minutes since UMA telecon 2022-06-30

  • Core UMA content/report (no use-case)

  • FAPI Part 1 Review and Discussion

  • Policy Descriptions

  • AOB

Attendees

  • NOTE: As of October 26, 2020, quorum is 5 of 8. (Michael, Domenico, Peter, Sal, Thomas, Alec, Eve, Steve)

  • Voting:

    • Alec

    • Steve

    • Sal

  • Non-voting participants:

    • Scott

    • Chris

    • Hanfei

  • Regrets:

Quorum: No



Meeting Minutes

Approve previous meeting minutes

Topics

Core UMA content (no use-case)

Continue discussion ‘UMA by example’ content

 

audience: NOT technical, business people - what value does uma provide a data custodian, users(?) - what value does uma provide the resource owner

  • problem that UMA addresses, user-mediate fine-grained authorization. person not present during access

  • physical access example(s), car or documents or airbnb(access to a physical space, RS) vs the specific thing (resource)

  • shift to access to digital resources/documents,

    • distributed nature of information: some at home, some with bank (safe deposit box), some with HCP,

    • controlling organization, who enforces access

  • GAP today: broadness of access, synchronous RO-only access, controlled by single org at a time

  • UMA applied to example

 

physical access vs digital access vs uma against use-case: car, documents, building access

 

General intro to Authorization: through example, lending

base example, lending car or documents? → broad authZ open garage everything is there. In uma, only the car is there

 

home example, loaning car in the garage

condo example, valet key

digital example: car manufacturer managed sharing,

uma example: user managed sharing

 

car, access to the garage, key to the car → broad since can access anything in the garage, key to glovebox. “Allowed to drive between 12-3, not more than 20mi”

condo concierge: RO not present, with someone enforcing my wishes

 

→ shift to digital

 

FAPI Part 1 Review and Discussion

https://fapi.openid.net/ 

Part 1: Baseline https://openid.net/specs/openid-financial-api-part-1-1_0.html

 

5.2.2. Authorization server

15. shall return the list of granted scopes with the issued access token if the request was passed in the front channel and was not integrity protected;

  • which request, token request? scopes in token response? when would there not be 'integrity protected'? there would always be TLS/client authn? is this for public clients?

17. should clearly identify the details of the grant to the user during authorization as in 16.18 of OIDC;

  • for pushed claims, would the Client have this responsibility? or would pushed claims need to be ‘off’ in FAPI

NOTE: The requirement to return the list of granted scopes allows clients to detect when the authorization request was modified to include different scopes. Servers must still return the granted scopes if they are different from those requested.

  • always return scopes or only under conditions of #15?

 

Could an UMA Auth Server support OIDC and the openid scope? tentative yes

  • there are naming differences eg redirect_uri vs claims_redirect_uri, code vs ticket

 

Overall, and UMA AS should be able to support FAPI basiline profile (part 1)

 

 

Policy Descriptions



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

  • 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

  • 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

Upcoming Conferences

  • IIW 35,  November 15 - 17