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_…
>>
>
Hi everyone,
Please take a look at
https://github.com/uma-email/poc#protected-dynamic-client-registration.
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
