- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2021-06-10
by Alec Laws 08 Jun '21

08 Jun '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10 Date and Time - *Primary-week Thursdays 6:30am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2021-04-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22> , UMA telecon 2021-04-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29> , UMA telecon 2021-05-06 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06> , UMA telecon 2021-05-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-13> , UMA telecon 2021-05-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-20> , UMA telecon 2021-05-27 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-27> , UMA telecon 2021-06-03 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-03> - Charter Refresh (tentative vote) - Group Leadership (review nominations, tentative vote) - Relationship Manager - draft with credentials - AOB

1 0

Draft minutes of UMA telecon 2021-06-03
by Alec Laws 03 Jun '21

03 Jun '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-03 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2021-04-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22> , UMA telecon 2021-04-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29> , UMA telecon 2021-05-06 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06> , UMA telecon 2021-05-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-13> , UMA telecon 2021-05-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-20> , UMA telecon 2021-05-27 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-27> Deferred Charter Review/Refresh Please review the Draft Charter 2021 <https://kantarainitiative.org/confluence/display/uma/Draft+Charter+2021>, changes have been highlighted in red. (5) - A horizontal UMA security profile, considering other profiles including HEART, FAPI, and OAuth 2.1 Changes to Group Leadership - we need to renew our annual voting roles, Chair and Vice-Chair - Next quorum we'll need to discuss and ideally vote on this topic - *Feel free to send nominations to the list* so we're prepared at our next quorum. Alec will send a separate note to the list to raise this request - If you have a voting membership, please let Alec know if you can/can't attend next week Relationship Manager The last session was recorded, check it out so these will make sense Discussed the merits of having a credential (public key) registered at the RS for a Resource Owner, and the different use-cases it starts to enable, both for UMA and getting into VC/SSI. - RO can sign policy it writes to the AS. The RS can have less trust in the AS since it's really trusting the RO - Today the RS trusts the AS as the RO. With the credential, the RS can trust *any* AS - Give the RO some more fiduciary capability aside from system-system (RS-AS) trust. This is part of Decentralized ID value prop - RO can delegate directly to other RqPs - Can this help the RS, not have to trust the RO as much? ANCR established the RO establish terms with any other system - Binding is the most critical bit of the trust flow. CIBA also solves for this, in a way that a RqP - UMA helps Alice ensure, that Bob is who he says, such that her policy can be applied to his request for Access - CIBA helps Bob ensure Alice is who she is. Currently we don't strongly bind Alice to the AS - Can we bind Alice to the AS, in a way the requesting party can confirm who she is? - ANCR wants to capture all this trusted state so that all parties can have this transparency, including getting Witnesses just in time. (parallels to a KERI witnesses, there is cryptogrpahic binding + attestation over an identifier) - ie UMA pushed claims, where the AS can 'ask for more' from a trusted third party (the Witness) - RS can issue to Alice, VCs. Either resource's as a VC, or actually data-containing VCs. Alice is then free to delegate and use from there. (The ssi credential exchange api) RS <strong trust> RO <> AS RS <> AS <> RqP <> RPT{Alice's proof} <> RS Alec will update the last RM Draft to: - Add back the credential, drop Authorization Servers API from it. - We're shifting the trust from the Fedz Auth api to the RO through their credential. AOB - will be looking to setup an ANCR presentation to the Group is around a month. Sal will let us know when he's ready 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. Michael 2. Steve 3. Eve 4. Alec 5. Sal 6. Domenico Non-voting participants: 1. Scott 2. Colin Regrets:

1 0

Agenda for UMA telecon 2021-06-03
by Alec Laws 03 Jun '21

03 Jun '21

1 0

Update
by Eve Maler 02 Jun '21

02 Jun '21

Hi everybody– I’m sorry for having to miss so many meetings in the last few months, but very grateful to Alec for stepping in and taking such a big leadership role in the WG, and everybody for continuing to contribute all the great work. While healthwise I'm okay now, given my day-to-day responsibilities I do need to “share” regular participation with more of my colleagues, Steve in particular. This will be a good thing! However, I think it means the end of my official chairmanship. I’m happy to to continue to pitch in on wiki editing, public speaking, and other assistance in a “chair emeritus” role, if there’s such a thing. Just let me know how I can help. Eve Maler | cell and Signal +1 425.345.6756

1 0

Towards AEMS
by Igor Zboran 01 Jun '21

01 Jun '21

Hi Eve, Alec, everyone, I drove the idea of ticket challenge further, to the concept of UMA-compliant communications platform, that does not interfere with the existing email infrastructure. Interaction with SMTP and IMAP servers is used only if the user has to explicitly demonstrate control of their email address – usually if WebFinger is not available to bootstrap the discovery of claims provider configuration from the email address. I will use this concept to complete the AEMS project. Please see the updated sequence diagrams at: https://github.com/uma-email/poc Regards -Igor

1 0

Draft minutes of UMA telecon 2021-05-27
by Alec Laws 27 May '21

27 May '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-27 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2021-04-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22> , UMA telecon 2021-04-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29> , UMA telecon 2021-05-06 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06> , UMA telecon 2021-05-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-13> , UMA telecon 2021-05-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-20> Deferred Genomics is a very interesting topic as the data always have multiple subjects. There are many complex layers to genesis data, chunk, sequence, images, etc. Eve has heard of a group working on set of permissions around the use of genomics data, could be made into APIS. Nancy notes another group, PP2PI (patient privacy 2 promote interoperability). Reach out to Nancy if you want to see the group Charter Review/Refresh (2) purpose "For example, working with the Kantara Consent and Information Sharing Work Group" → Kantara or external consent-oriented work groups (add some examples, eConsent) "To promote interoperability of independent implementations of UMA", (keep this and add:) could this support wider interop? such as with HEART/OIDC - "To promote interoperability between UMA and other related - "To promote the use of UMA to provide authorization capabilities to - Consider 3rd party requests to standardize profiles and extensions where there is wider applicability of the profile - Review, evaluation and recommendation of submitted implementation profiles of UMA - (already covered by point 1) (3) (4) remove "Business Model Clause Templates for User-Managed Access (this may be a report instead; final title to be determined)" add Relationship Manager/Policy Manager/Resource Definition drafts (5) - GNAP / OAuth 2.1, (sender constrained tokens, no implicit, pkce) we're there other oauth extensions pulled in, or 2.1 is only OAuth2 + BCP? - would we accept an UMA profile based on GNAP instead of OAuth? Should UMA be GNAP-ready when it is released? - transition from Oauth to GNAP? - evaluation of UMA-like things on different authorization protocols, profile of GNAP - evaluation of claims token beyond IDTokens (VCs?) DO we need to define the different between implementation(/deployment profiles and guidance** - implementations = the vendors who have UMA impls - deployments = 'fully baked' systems that use UMA (PDP, FPX) UMA + X, profiles - HEART, FAPI, Consent Receipt * This draft consolidates the functionality in OAuth 2.0 [RFC6749], OAuth 2.0 for Native Apps ([RFC8252]), Proof Key for Code Exchange ([RFC7636]), OAuth 2.0 for Browser-Based Apps ([I-D.ietf-oauth-browser-based-apps]), OAuth Security Best Current Practice ([I-D.ietf-oauth-security-topics]), and Bearer Token Usage ([RFC6750]). * Where a later draft updates or obsoletes functionality found in the original [RFC6749], that functionality in this draft is updated with the normative changes described in a later draft, or removed entirely. * A non-normative list of changes from OAuth 2.0 is listed below: * The authorization code grant is extended with the functionality from PKCE ([RFC7636]) such that the default method of using the authorization code grant according to this specification requires the addition of the PKCE parameters * Redirect URIs must be compared using exact string matching as per Section 4.1.3 of [I-D.ietf-oauth-security-topics] * The Implicit grant ("response_type=token") is omitted from this specification as per Section 2.1.2 of [I-D.ietf-oauth-security-topics] * The Resource Owner Password Credentials grant is omitted from this specification as per Section 2.4 of [I-D.ietf-oauth-security-topics] * Bearer token usage omits the use of bearer tokens in the query string of URIs as per Section 4.3.2 of [I-D.ietf-oauth-security-topics] * Refresh tokens should either be sender-constrained or one-time use as per Section 4.12.2 of [I-D.ietf-oauth-security-topics] UMA + Consent Receipts City University Birmingham have a demo showing how UMA works with Consent Receipts. Was in a healthcare context Is there interest in setting up a joint UMA + CR WG call to review this? yes. Sal is going to dig up the link and share on the mailing list OIDF Liaison Any one interested in creating an UMA FAPI profile? There was a draft shared, but never signed. Do we need to finish this, and what is the purpose? To support maintenance of HEART + future FAPI UMA profile Relationship Manager Review Deferred AOB 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. Steve 2. Michael 3. Eve 4. Thomas 5. Alec Non-voting participants: 1. Colin 2. Scott 3. Tim 4. George 5. Zhen - learned about group from ONC AGM. Training in biomedical informatics, interested in genomic privacy. Patients hardly ever in the use of their data! 6. Nancy 7. Sal Regrets:

1 0

Agenda for UMA telecon 2021-05-27
by Alec Laws 26 May '21

26 May '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-27 UMA telecon 2021-05-27Date and Time - *Primary-week Thursdays 6:30am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2021-04-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22> , UMA telecon 2021-04-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29> , UMA telecon 2021-05-06 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06> , UMA telecon 2021-05-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-13> , UMA telecon 2021-05-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-20> - Relationship Manager Review, discuss credential concept - AOB

1 0

UMA Deep Dive
by Igor Zboran 25 May '21

25 May '21

Hi Eve, Alec, Hi everyone, UMA was originally designed for B2B scenarios, whereas OAuth2 was designed for B2C scenarios. In OAuth2 the roles of the authorization server, resource server and client are co-located. This does not apply to the UMA protocol. RqP's role is not co-located with other UMA roles, RqP is like a foreigner with a passport issued in his home country. We need to specify how to issue this "passport", and how to use and control it. A good starting point could be this idea: UMA should convey the permission ticket in the form of a ticket digest to the claims provider, to have it digitally signed together with user claims and return all this as a claims token, which is pushed to the AS in an uma grant request. What does it mean? The permission ticket is extended to embrace the claims provider. Regards -Igor

2 3

Fwd: [Cups-friends] [CFP] Seventh International Workshop on Privacy Engineering (IWPE'21)
by Eve Maler 23 May '21

23 May '21

This may be of interest. > Begin forwarded message: > > From: Blagovesta Kostova <blagovesta.pirelli(a)epfl.ch> > Subject: [Cups-friends] [CFP] Seventh International Workshop on Privacy Engineering (IWPE'21) > Date: 13 May 2021 at 10:06:27 AM CDT > > CFP: Seventh International Workshop on Privacy Engineering (IWPE'21) > http://iwpe.info/ <http://iwpe.info/> > co-located with the IEEE European Symposium on Security and Privacy <https://www.ieee-security.org/TC/EuroSP2021/index.html> > September 7th, 2021 - online > > ************************************************************ > IMPORTANT DATES > Deadline of paper submission: May 15, 2021 (extended) > Notification of acceptance: June 8, 2021 > Accepted Paper camera ready: June 22, 2021 (non-archival option available) > ************************************************************ > We are pleased to invite you to participate in the 7th International Workshop on Privacy Engineering (IWPE'21). > > Ongoing news reports regarding global surveillance programs, massive personal data breaches in corporate databases, and notorious examples of personal tragedies due to privacy violations have intensified societal demands for privacy-friendly systems. In response, current legislative and standardization processes worldwide aim to strengthen individual’s privacy by introducing legal, organizational and technical frameworks that personal data collectors and processors must follow. > > However, in practice, these initiatives alone are not enough to guarantee that organizations and software developers will be able to identify and adopt appropriate privacy engineering techniques in their daily practices. It is also difficult to systematically evaluate whether the systems developed comply with legal frameworks, provide necessary technical assurances, and fulfill users’ privacy requirements. It is evident that research is needed in developing techniques and tools that can aid the translation of legal and normative concepts, as well as user expectations into systems requirements. Furthermore, methods that can support organizations and engineers in developing systems that address these requirements are of increasing value. > > In this context, privacy engineering research is emerging as an important topic. Engineers are increasingly expected to build and maintain privacy-preserving and data-protection compliant systems in domains such as health, energy, transportation, social computing, law enforcement, public services; based on different infrastructures such as cloud, grid, or mobile. While there is a consensus on the benefits of an engineering approach to privacy, concrete proposals for models, methods, techniques and tools that support engineers and organizations in this endeavor are few and in need of immediate attention. > > To cover this gap, the topics of the International Workshop on Privacy Engineering (IWPE'21) focus on all the aspects of privacy engineering, ranging from its theoretical foundations, engineering approaches, and support infrastructures, to its practical application in projects of different scale. Specifically, we are seeking the following kinds of papers: > (1) technical papers that illustrate the engineering or application of a novel formalism, method or other research finding (e.g., a privacy enhancing protocol) with preliminary evaluation; > (2) experience and practice papers that describe a case study, challenge or lessons learned from in a specific domain; > (3) early evaluations of methods, tools and other infrastructure that support privacy-related tasks; > (4) interdisciplinary studies or critical reviews of existing privacy engineering concepts, methods, tools and frameworks; > (5) vision papers that take a clear position informed by evidence based on a thorough literature review. > > IWPE’21 welcomes papers that focus on novel solutions on the recent developments in the general area of privacy engineering. Topics of interest include, but are not limited to: > -Integrating law and policy compliance into the development process > -Privacy impact assessment during software development > -Privacy risk management models > -Privacy breach recovery Methods > -Technical standards, heuristics and best practices for privacy engineering > -Privacy engineering in technical standards > -Privacy requirements elicitation and analysis methods > -User privacy and data protection requirements > -Management of privacy requirements with other system requirements > -Privacy engineering strategies and design patterns > -Privacy-preserving architectures > -Privacy engineering and databases, services, and the cloud > -Privacy engineering in networks > -Engineering techniques for fairness, transparency, and privacy > -Engineering privacy in AI and ML > -Privacy engineering in the context of interaction design and usability > -Privacy testing and evaluation methods > -Validation and verification of privacy requirements > -Privacy Engineering and design > -Engineering Privacy Enhancing Technologies (PETs) > -Integration of PETs into systems > -Models and approaches for the verification of privacy properties > -Tools and formal languages supporting privacy engineering > -Teaching and training privacy engineering > -Adaptations of privacy engineering into specific software development processes > -Pilots and real-world applications > -Evaluation of privacy engineering methods, technologies and tools > -Privacy engineering and accountability > -Privacy engineering and business processes > -Privacy engineering and manageability of data in (large) enterprises > -Organizational, legal, political and economic aspects of privacy engineering > This topic list is not meant to be exhaustive; since IWPE'21 is interested in all aspects of privacy engineering. > > ************************************************************ > PAPER FORMAT & SUBMISSION > We solicit unpublished short position papers (up to 4 pages) and long papers reporting technical, research or industry experience (up to 8 pages) on all dimensions of the privacy engineering domain. Each paper, written in English, must follow IEEE Proceedings format. > Submission of a paper should be regarded as an undertaking that, should the paper be accepted, at least one of the authors will attend the workshop to present the paper. All papers must be submitted via EasyChair at https://www.easychair.org/conferences/?conf=iwpe21 <https://www.easychair.org/conferences/?conf=iwpe21> > IWPE offers the choice of archival and non-archival paper submissions. The non-archival option is offered to avoid precluding future submissions to area-specific venues. Accepted archival submissions will be published in IEEE eXplore, which is indexed by EI Engineering Index, ISI Conference Proceedings Citation Index (CPCI-S), Scopus, etc. > > ************************************************************ > If you have any questions regarding IWPE'21, please contact iwpe21(a)easychair.org <mailto:iwpe21@easychair.org> > > IWPE’21 Organizing Committee > Jose M. del Alamo > Isabel Wagner > Kim Wuyts > Isabel Barberá > Blagovesta Kostova > > > _______________________________________________ > Cups-friends mailing list > Cups-friends(a)mailman.srv.cs.cmu.edu <mailto:Cups-friends@mailman.srv.cs.cmu.edu> > https://mailman.srv.cs.cmu.edu/mailman/listinfo/cups-friends <https://mailman.srv.cs.cmu.edu/mailman/listinfo/cups-friends> Eve Maler | cell and Signal +1 425.345.6756

1 0

Draft minutes of UMA telecon 2021-05-20
by Alec Laws 20 May '21

20 May '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-20 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2021-04-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-22> , UMA telecon 2021-04-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-04-29> , UMA telecon 2021-05-06 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-06> , UMA telecon 2021-05-13 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-05-13> Deferred Pension Dashboard Update https://kantarainitiative.org/uma-profile-for-uk-pensions-dashboard-program… No changes, will remove from Agenda until September. Some people have found the profile through the webpage. OIDF Liaison Trying to find out if one exists or yet to be assigned. This came up recently in context of creating an UMA FAPI profile. Is there any takers to draft how this would look? Relationship Manager Review https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ 2021-05-20 13.24 UMA Working Group.mp4 <https://kantarainitiative.org/confluence/download/attachments/144016363/202…> AOB 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. Peter 2. Eve 3. Alec 4. Michael 5. Steve Non-voting participants: 1. Scott 2. Colin Regrets:

1 0