https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-11-04
Minutes
Roll call
- Quorum: No
Approve minutes
- Approve minutes of UMA telecon 2021-09-09
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09>
, UMA telecon 2021-09-16
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16>
, UMA telecon 2021-09-23
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-23>
, UMA telecon 2021-09-30
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-30>
, UMA telecon 2021-10-14
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-14>
, UMA telecon 2021-10-21
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-21>
, UMA telecon 2021-10-28
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-28>
Deferred
*The Kantara All members meeting is Dec 8th, 11-1230ET (it's virtual, link
TBD)*
FHIR Vulnerability Report
Working document here: Report on FHIR API Vulnerabilities
<https://kantarainitiative.org/confluence/display/uma/Report+on+FHIR+API+Vul…>
Please take a look, all comments/contributions welcomed! There original
report is attached to the confluence page
OAuth vs UMA content
previous discussion: UMA telecon 2021-09-16
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16>
Who is the right audience for this content? a version at different
'levels'? Show value to Business & Technical separately,
At biz level, there is buy into 'OAuth is awesome' and creates the question
"so why do I need UMA?"
- 'putting you lock on the wrong locker' UMA helps prevent this mistake
- you can apply Oauth to protect an API, however the solution still
needs to consider who's who (authN) and who has access to what (authZ)
Maybe it's 'what's oauth' and then a 'what's UMA to follow up'
Here' the problem UMA addresses: it allows a person to control their stuff,
and how they want to share it with somewhere else. OAuth is an underlying
technology to authorize the requestor. eg give Alice the ability to call
the help desk to give her Mom or spouse access to her record. UMA gives
Alice the ability to do this herself. THe cost reduction of self-service
access is similar to removing manual 'forgot password' flow.
By using UMA, it reduces the custom development of these features in
existing stacks. UMA services come with these features off the shelf, shift
custom impl to configuration. (Except policy which is... left to the reader)
Removes requirements from the enterprise by given the user the direct
ability to manage their stuff themselves.
Google drive sharing is the best practical example of this (even though it
doens't use UMA [image: (sad)]).
What is the best format for this content?
- 2-3 slides that members can easily re-use
What about UMA vs GNAP? Will GNAP replace OAuth and UMA?
Have never heard a customer request GNAP, only discussion within the
IETF/OAuth/UMA communities.
Check out the recent GNAP progress here:
https://github.com/ietf-wg-gnap/gnap-core-protocol
Is there a clear UMA → GNAP transition?
PAT lifecycle management
PAT lifecycle management, it is a OAuth access token, with expiration and
refresh token
When it's needed (eg when a client makes a request) it can be expired
How long should it live?
- the PAT itself it an access token and should expire in a short window
(eg normal access token, such as 5mins)
- the refresh token can have a loooong lifetime, eg months/years
- the PAT represents the ROs authorization for the RS to trust the AS,
and for the AS to protect the RS's API
- it should expire aligned with that human level policy around
expiration
What to do if the PAT and it's refresh have expired? Need the RO to come
back and regenerate it
- should there be a different message to the client? It's not the RO at
the client, instead it's the RqP. We shouldn't expose the maintenence of
the PAT to the RqP
- the RS can't issue a ticket to the RqP
- there is no definied response in this case, is it a 403? there is no
appropriate www-authenticate type redirect
- UMA Implementer's
Guide#pat-invalidResourceServerErrorHandlingWhenthePATIsInvalid
<https://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gu…'sGuide-pat-invalidResourceServerErrorHandlingWhenthePATIsInvalid>
- return a 403 with http error and header 'Warning: 199 - "UMA
Authorization Server Unreachable"'
- ideally there is some RS → RO notification to renew
Depends on the RO model. When the RO is the RS, the RS can always get a new
PAT using it's client credentails
If the RO is a proper subject, then these challenges all exist
Could the AS always allow a RS=RO PAT, how would this interact/intersect
with proper subject RO bounded PATs?
A not-uma solution (relationship manager solution)
RS <> AS: resources registered (eg /patient)
RS → RO: 'id token' with the subject id (alec123)
RO → AS: the RS knows me as alec123, I want to give Bob access to /patient
for that subject
AS → RS: introspection result returns resource and subject id
AOB
- We are planning a 3 hour working session on December 9th, we will use
extend the normal call from 930-1230ET
- Want to make progress on some of the in-progress docs, have them in
a consistent state
- Eve, Nancy, Alec, Andi
- If you're up to attend, please email Alec, or leave a comment on
these minutes
Next week, Steve will give a de-brief of the FIDO authenticate conference
Topic Candidates (from previous week's telcon)
- Delegation and Guardianship
-
Outcome of user stories discussion
-
PDP architecture includes the concept of governance registry/discovery
-
TOIP/SSI are starting to define this ecosystem function
-
ANCR records update
-
Privacy as Expected/ANCR update : 2/3 weeks out (Sal?)
Attendees
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:
1. Sal
2. Alec
3. Domenico
4. Steve
Non-voting participants:
1. Scott
Regrets:
1. Nancy
2. Eve
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-21
MinutesRoll call
- Quorum: No
Approve minutes
- Approve minutes of UMA telecon 2021-09-09
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09>
, UMA telecon 2021-09-16
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16>
, UMA telecon 2021-09-23
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-23>
, UMA telecon 2021-09-30
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-30>
, UMA telecon 2021-10-14
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-14>
Deferred
IIW closing thoughts
(see initial thoughts from last weeks minutes)
- a lot of SSI focus, main OAuth-y topics we're in relation to the
interop/connection to SSI
FHIR Vulnerability Review
and how UMA could address, maybe a 1-2 page position
https://www.scmagazine.com/analysis/application-security/critical-flaws-fou…https://www.healthcareitnews.com/news/cybersecurity-briefs-olympus-it-outag…
Summary of articles: a white-hat security company (https://approov.io/)
have looked at some health care mobile applications that access FHIR apis.
Patients were authenticating against the API/EHR, however the applications
were able to access all FHIR data regardless of the authenticated user.
There were also issues raised around static client credentials embedded in
the mobile applications (public SMART on FHIR app using confidential client
creds?)
- no patient/RO segmentations, seems that any authenticated user could
access the full API
- coarse grained api access, no RO compartmentalization
- want apps to conform to their requirements and protect data
want to avoid a 'shut down access' reactive response
Potential Outline:
- summary of the issues found
- assumed oauth/oidc api model being used
- identity is often an invitation model for EHRs
- present a uma architecture to show the fine grained RO resources
- how that helps the FHIR API provider properly restrict access. only
one patients at a time
- direct responses to the 'Recommendations to FHIR API Owners"
- use of high assurance identity
- other uma benefits
- multiple idps, don't make the FHIR API provider deal with
authentication/identity. UMA AS is connection between identity/authN
systems and the FHIR AuthZ
- sharing and delegation to Bob
- links to CARIN recommendations and app certification processes (eg as
provided by AEGIS)
application of provider authZ setup to patient access
difference of patient/*.* (what they should've done) and user/*.* (what
they did)
Patient empowerment group (hl7 group) is meeting and the article writer is
presenting these findings.
<https://confluence.hl7.org/display/PE/2021-10-21+Patient+Empowerment+Prelim…>
Let's use confluence, *Alec will create a page and move these notes over
then share the link on the mailing list*
AOB
- Delegation Use Cases
- pp2pi (protecting privacy to promote interoperability) use cases,
can we schedule a time to review. Nancy has the documents but can't share
them
- there is existing delegation use-cases documents that we may
refresh/update: eg
https://patientcentricsolutions.com/fileadmin/user_upload/Files/Report_UMA_…
- summarize how UMA can be used to support these use cases.
Delegation is viewed as hard, but can be addressed by trying to solve it
and considering the use-case
- This will be the main topic for next weeks call
- moving gdocs working docs to confluence, will create a working docs
space in confluence to upload these docs
- confluence has a 'import word doc' feature, need an approach for
slide decks
*Conference roundup*
In person is coming back!
- Identity North
- HLTH: https://www.hlth.com/
- in-person w/ 6000 people in attendance!
- FIDO Authenticate
- National Cyber Summit in Nashville
- zero trust was a main topic
- 2500 people!
Topic Candidates (from previous week's telcon)
- Delegation and Guardianship
-
Outcome of user stories discussion
-
PDP architecture includes the concept of governance registry/discovery
-
TOIP/SSI are starting to define this ecosystem function
-
ANCR records update
-
Privacy as Expected/ANCR update : 2/3 weeks out (Sal?)
Attendees
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:
1. Eve
2. Alec
3. Domenico
Non-voting participants:
1. Scott G, working with Healthcare team at Forgerock
2. Nancy
3. Vladimir
4. Scott
Regrets:
1. Steve
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-10-14
MinutesRoll call
- Quorum: No
Approve minutes
- Approve minutes of UMA telecon 2021-09-09
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09>
, UMA telecon 2021-09-16
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16>
, UMA telecon 2021-09-23
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-23>
, UMA telecon 2021-09-30
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-30>
Deferred
Document Development
GDocs/etc. is problematic so let's find an alternative and use it for
everything
- Maybe Kantara's github? good for publishing/versioning, maybe not best
for commenting
- Use markdown?
- Confluence? Good for commenting/iteration, can always move to github
to publish if necessary
Let's use *confluence* for document development.
If you need an account, it's easy to self-register (look at the top right
of this page). Reach out to Alec if you have issues
Protected Dynamic Client Registration
https://github.com/uma-email/poc#protected-dynamic-client-registration
If we want wide-ecosystems, then DCR is necessary and doesn't seem to need
more gates. The spec already includes software statements. What is the gap
in the existing spec that needs to be addressed?
The current proposed DCR links a client to a RqP. Is the intention that the
client always does DCR for each RqP, or the first RqP facilitates the
clients CDR?
Delegation and Guardianship
- https://patientcentricsolutions.com/resources
- https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper2.pdf
- Okta OSS implementations: "Delegate
<https://github.com/zeekhoo-okta/oktadelegate>" and "Managed Access
<https://github.com/AndyMarch/Okta-managedaccess>"
- Examples of attempts to layer UMA-like features on top of OAuth,
maybe could also be solved by OAuth 2 extensions such as token exchange
- Very custom paths to achieve impersonation and delegation
Goal, collect a few delegation/guardianship/association use cases and show
how to implement in UMA. glossary or report to analyze these cases in UMA
terms? Update to UMA Legal deck → report?
There is a set of UMA business use-cases already, including delegation of
decision making (substitute decision maker) and the process of establishing
that delegation.
There is a new set of use-cases for another group (pp2pi) that are
deliberately hard to achieve. Want to review these cases and see if
existing UMA cases cover them, or if we can build new UMA guidance to
address them.
On the 25th we can review the existing Use Case work, and compare with the
links above
If you have delegation use-cases, please bring them forward on the mailing
list
AOB
Anyone going to the FIDO Authenticate conference next week?
There are also OIDF meeting next Thursday
Recent news on FHIR vulns:
https://www.scmagazine.com/analysis/application-security/critical-flaws-fou…https://www.healthcareitnews.com/news/cybersecurity-briefs-olympus-it-outag…
IIW quick impressions:
- hugely focused on SSI/TOIP/DID/VC, very few OAuth/web authorization
based sessions
- people are trying to apply these new technologies to all transactions,
need to bring existing OAuth/UMA concept back into the discussion
- separating security from the transport protocol is a very interesting
idea. often the protocol security is linked to transport security (eg oauth
+ tls)
- challenges today are around interoperability, still trying to bring it
together, ex so any did method can be used in any VC scheme
- ideally we can bring some UMA content to the next IIW, show the
intersection between DID/VC and existing web authorization systems
Check out the mozilla objections to the DID spec:
https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.html
And a response from Evernym:
https://www.evernym.com/blog/w3c-vision-of-decentralization/
Topic Candidates (from previous week's telcon)
- Delegation and Guardianship
-
Outcome of user stories discussion
-
PDP architecture includes the concept of governance registry/discovery
-
TOIP/SSI are starting to define this ecosystem function
-
ANCR records update
-
Privacy as Expected/ANCR update : 2/3 weeks out (Sal?)
Attendees
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:
1. Eve
2. Alec
3. Steve
4. Sal
5. Thomas
Non-voting participants:
1. Scott
2. Zhen
3. George
4. Nancy
Hi George,
For single-page-apps the client registration endpoint may return the client
secret in the form of cookies with the HttpOnly and secure flags set.
Javascript will not be able to access the client secret and the front-end
developer does not have to fiddle with the secret. If the user deletes the
cookies, the client re-registers with the AS.
-Igor
On Wed, Oct 6, 2021 at 7:30 PM George Fletcher <george.fletcher(a)yahooinc.com>
wrote:
> For single-page-apps there is also DPoP [
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04] which
> provides some similar capabilities using ephemeral keys. The issue I see
> with DCR and SPAs is maintaining the keys in the browser in a persistent
> way.
>
> On Wed, Oct 6, 2021 at 7:11 AM Igor Zboran <izboran(a)gmail.com> wrote:
>
>> Hi everyone,
>>
>> Please take a look at
>> https://github.com/uma-email/poc#protected-dynamic-client-registration
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uma-2Demail…>
>> .
>>
>> This may solve the single page applications and native applications
>> problem with client secrets. I mean, the client is public with respect to
>> the IdP, and at the same time – after dynamic registration – confidential
>> with respect to the AS.
>>
>> Regards
>>
>> -Igor
>> _______________________________________________
>> WG-UMA mailing list
>> WG-UMA(a)kantarainitiative.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__kantarainitiative.org_…
>>
>
