Quorum was NOT reached.
Sal moves to approve. MOTION PASSES
Pensions Dashboard status update
Still working through IPR issues, this prevents the PDP from opening their procurement. The Pensions Dashboard Program is still planning to contribute some initial updates to the Origo contributed profiles. One option being explored is a separate Kantara WG for the purpose to working on this profile, that has a different group IPR policy. PDP wants the profiles to be open, so that there are no barriers for suppliers/vendors to implement
Sal notes there always seem to be IPR issues at some point. Changing work group IPR is hard, as the effect on previously created documents is not clear. There is some recent precedent with the proposed ANCR (advanced notice and consent receipt) WG with a different IPR policy from the ISI WG.
LC Speakers Corner topic
There is a new Kantara initiative to have a new once a month session where a WG can share a topic with the wider Kantara community and receive feedback/input. The first session is tentatively scheduled for Feb 17 at 11:30 ET. UMA is up first!
Two current work items to be shared are the UK Pensions Profile and the Wallet profiles
If there are other topics that group members are interested in sharing with the wider Kantara community. Please reach our to Alec or the mailing list!
There was some work on delegation within UMA done by Eve/Lisa that would be interesting to heard at our UMA WG. This would also be a great topic to share more widely with Kantara to get more input
UMA + US Health Care Update
There are some US Health care initiatives looking at decentralized consent. There have been many issues raised with sharing 'consent' between system, specifically in sharing the PHI inherent in any consent record. Instead of 'federated' Sal suggests a 'decentralized' approach which may address some of the sharing of consent. In UMA, the consent record isn't shared, the decision or outcome is. With a 'consent repository' what could be shared is a 'pointer' to the consent, similar to a resource uri, and proper authorization would need to be attained before seeing the content of the consent record. The FHIR consent resource has PHI like all FHIR resources, however the authorization/sharing of 'other' FHIR resources is often dependant on the existence of a Consent resource. The UMA AS or wallet model protects the consent and separates it from the protected resources, however, the pure UMA model get's into multiple ASs hosted by many health care sites, the Person must then manage consent many places. UMA and
UMA + Standard OAuth mix-up attack and mitigation
There is a new IETF Draft (OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response) to standardize of the Mix-up attack mitigations. Our current Implementer's Guide references the OAuth BCP as additional considerations for UMA implementations. Should we reference this new draft?
Mix-up only relevant where an RP talks to many Authorization Servers, ie a wide ecosystem where a client is introduces dynamically to new AS's. The main mitigation from the BCP is to use a unique redirect uri for each AS. The new draft allows reuse of the callback, by adding a new `iss` param only the callback which the RP must compare to their expect value, ie where the sent the user for authorization.
No major impact on UMA. Alec will update the UMA implementors Guide to reference this new draft to help people find it
Ian has a topic for next call around FAPI/UMA
As of October 26, 2020, quorum is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)