- WG-UMA - mailman.kantarainitiative.org

IETF 104 OAuth sessions are now on the UMA WG calendar / summertime skew
by Eve Maler 12 Mar '19

12 Mar '19

https://kantarainitiative.org/confluence/display/uma/Calendar If you would like me to include an invitation to you on these calendar entries, please send me a note. The entries have links that explain how you need to register ahead of time for remote participation. As of this week and until March 31, we're in the "summertime skew" period where the US has sprung forward but Europe has not done so yet. The Monday (Mar 25) is the day we're presenting, and the time zone works out pretty well for people in the US. Beware that the Thursday (Mar 28) is not all that great. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

For immediate action (by some): Implementer's Draft vote on HEART profiles
by Eve Maler 08 Mar '19

08 Mar '19

*For those of you who are OpenID Foundation members:* The latest HEART (Health Relationship Trust) profiles, which include profiling UMA2 for the first time, are up for an Implementer's Draft vote. More information, including a link to the ballot (poll) itself, can be found here: https://openid.net/2019/02/18/notice-of-vote-for-implementers-drafts-of-fou… The voting deadline is *next Monday*. If you're an OIDF member, please consider taking the time right now to vote. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Fwd: Reminder: Request for Review and Comment: PCTF (Pan Canadian Trust Framework) Model Overview / rappel: Demande de révision et de commentaire: Model aperçu du cadre de confiance pancanadien
by Eve Maler 01 Mar '19

01 Mar '19

I’ve been meaning to forward this for people’s potential interest. Eve Maler (sent from my iPad) | cell +1 425 345 6756 Begin forwarded message: > From: "review(a)diacc.ca" <review(a)diacc.ca> > Date: March 1, 2019 at 1:02:57 PM CST > To: Eve <eve(a)xmlgrrl.com> > Subject: Reminder: Request for Review and Comment: PCTF (Pan Canadian Trust Framework) Model Overview / rappel: Demande de révision et de commentaire: Model aperçu du cadre de confiance pancanadien > > French version to follow > Eve Maler > This is a reminder that if you have not had the opportunity to provide us your feedback on the Pan-Canadian Trust Framework (PCTF) Model Overview Discussion Draft there is still time. The deadline for your input is March 15, 2019 at 23:59 PST. > Thank you for your valued input. > review(a)diacc.ca > Invitation: > DIACC is pleased to provide the Pan-Canadian Trust Framework (PCTF) Model Overview Discussion Draft. DIACC invites all interested parties to comment including identity issuers, identity consumers, developers, and potential users. > Context: > The purpose of the open commentary is to ensure transparency in development and diversity of truly Pan-Canadian, and international, input. This discussion draft has been developed by the DIACC Trust Framework Expert Committee (TFEC) that operates under the DIACC controlling policies. In alignment with our Principles for an Identity Ecosystem, processes to respect and enhance privacy are being prioritized through every step of the PCTF development process. > DIACC expects to modify and improve this discussion draft based on public comments. Comments made during the review will be considered for incorporation to the next draft and DIACC will prepare a disposition of comments to provide transparency with regard to how each comment was handled. This draft will be translated to French when it becomes more stable. > To learn more about the broad Pan-Canadian Trust Framework vision and benefits-for-all value proposition please review the Pan-Canadian Trust Framework Overview | Aperçu du cadre de confiance pancanadien. > PCTF Model Overview Summary: > The purpose of this document is to provide a high-level overview of the Pan-Canadian Trust Framework (PCTF). The document includes a recap of contextual information, PCTF goals and objectives, and an outline of the functional areas with which the PCTF is primarily concerned. This outline provides readers a general sense of the information with which the PCTF is concerned and the various processes involved in creating, managing, and using that information. Individual PCTF component documents provide detailed descriptions of every function and process that are part of the digital identity domain. > Documents: > · PCTF Model Overview Discussion Draft V0.02 PDF > · DIACC Comment Submission Form Spreadsheet > Period: > · Opens: February 13, 2019 at 23:59 PST > · Closes: March 15, 2019 at 23:59 PST > Process: > · All comments submitted are subject to the DIACC contributor agreement > · Log comments in the provided DIACC Comment Submission Form Spreadsheet > · Be sure to reference the corresponding line number found in the PCTF Model Overview Discussion Draft for each comment submitted > · Email completed DIACC Comment Submission Form Spreadsheet to review(a)diacc.ca > · Questions may be sent to review(a)diacc.ca > Ceci est un rappel que si vous n’avez pas eu l’occasion de nous faire part de vos commentaires sur l’ébauche de discussion sur l’aperçu du modèle du Cadre de confiance pancanadien, il y a encore temps. La date limite pour vos commentaires est le 15 mars 2019 à 23h59 HNP. > Merci pour votre contribution. > review(a)diacc.ca > Invitation > Le DIACC a le plaisir de vous soumettre le document de travail sur l’aperçu du modèle de cadre de confiance pancanadien (CCP) et invite toutes les parties intéressées – émetteurs et consommateurs d’identité, développeurs et utilisateurs potentiels – à le commenter. > Contexte > Les commentaires ouverts ont pour but d’assurer une transparence dans l’élaboration et la diversité d’une contribution véritablement pancanadienne et internationale. Ce document de travail a été préparé par le Comité d’experts du cadre de confiance du DIACC, qui est régi par les politiques de contrôle du DIACC. Conformément à nos principes pour un écosystème de l’identité, la priorité est accordée aux processus à respecter et à une confidentialité accrue à chacune des étapes du développement du CCP. > Le DIACC s’attend à modifier et à améliorer ce document de travail en fonction des observations du public. Les commentaires effectués pendant l’examen seront pris en compte en vue d’être incorporés dans la prochaine ébauche, et le DIACC va préparer un recueil de commentaires afin d’indiquer de façon transparente la façon dont chaque commentaire a été traité. Cette ébauche sera traduite en français une fois qu’elle sera plus définitive. > Pour en savoir davantage sur la vision du cadre de confiance pancanadien et la proposition de valeur dans l’intérêt général, nous vous invitons à prendre connaissance de l’Aperçu du cadre de confiance pancanadien | Pan-Canadian Trust Framework Overview. > Résumé de l’aperçu du modèle de CCP > Ce document a pour but de fournir un aperçu général du cadre de confiance pancanadien (CCP). Il comprend une récapitulation des renseignements contextuels, et des buts et objectifs du CCP, ainsi qu’une présentation des domaines fonctionnels qui interpellent surtout le CCP. Cet aperçu donne aux lecteurs une idée générale des renseignements auxquels le CCP s’intéresse, et des divers processus intervenant dans la création, la gestion et l’utilisation de ces renseignements. Les différents documents qui composent le CCP fournissent des descriptions détaillées de chaque fonction et processus faisant partie du domaine de l’identité numérique. > Documents > · Document de travail sur l’aperçu du modèle de cadre de CCP V0.02 PDF > · Formulaire pour soumettre des commentaires au DIACC (fichier Excel) > Période > · Début : 13 février 2019 à 23 h 59 heure du Pacifique > · Fin : 15 mars 2019 à 23 h 59 heure du Pacifique > Processus > · Tous les commentaires soumis sont assujettis à l’Accord de contribution avec le DIACC. > · Les commentaires doivent être entrés dans le formulaire de soumission (fichier Excel) destiné au DIACC. > · Assurez-vous d’utiliser le numéro de ligne correspondant que vous trouverez dans le document de travail sur le modèle de CCP pour chaque commentaire soumis. > · Le formulaire de soumission des commentaires doit être envoyé par courriel, dûment rempli, au DIACC à review(a)diacc.ca. > · Les questions peuvent être adressées à review(a)diacc.ca

1 0

Draft minutes of UMA telecom 2019-02-28
by Eve Maler 28 Feb '19

28 Feb '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-02-28 MinutesRoll call Quorum was reached. Approve minutes - - Approve minutes of UMA telecon 2019-02-21 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-02-21> MOTION: Andi moves to approve minutes of UMA telecon 2019-02-21 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-02-21>: APPROVED by unanimous consent. IETF presentation prep - Eve to send around a draft The OAuth WG has biweekly "virtual office hours" and Eve joined the last such meeting this week. She presented a bit about UMA2 by reviewing the Introductions of the two specs. The two OAuth sessions are going to be <https://datatracker.ietf.org/meeting/104/agenda/> on the Monday afternoon and Thursday morning (this could change). We're hoping for a Monday presentation time. Maciej, Pedro, now Neil Madden, and possibly Andi are currently planning to go (this also could change). We discussed and worked on the emailed slide deck draft. Let's plan to review in email and Skype chat. We have no meeting next week (Mar 7) due to RSA, but we have two more chances to meet before IETF 104. Interop testing and Identiverse Andi and Eve will meet, hopefully next Sunday morning, to discuss putting together an Identiverse "showing off the results of UMA interop testing" session. Gluu has shipped its Gateway and we could potentially use that for a "standardized" RS component in order to test AS functionality. There seems to be interest in sufficient quarters. Most implementations don't support interactive claims gathering so we could just test pushed claims for now. High assurance of the RO to the RqP - If time and Peter is available Deferred. Attendees As of 18 Oct 2018, quorum <https://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Peter 3. Sal 4. Andi 5. Eve 6. Mike Non-voting participants: - George - Alec - Scott - Nancy - Thomas - Bjorn Regrets: - Cigdem - Tim - Lisa *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

IETF 104 slide draft to look at today
by Eve Maler 28 Feb '19

28 Feb '19

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2019-02-28
by Eve Maler 27 Feb '19

27 Feb '19

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-02-28 Date and Time - *Thursdays 6am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2019-02-21 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2019-02-21> - IETF presentation prep - Eve to send around a draft - High assurance of the RO to the RqP - If time and Peter is available - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

To decide by Thursday: Identiverse interop slot?
by Eve Maler 26 Feb '19

26 Feb '19

Andi had kindly held out to us an opportunity to run some kind of interop session at Identiverse this year. The time to decide is upon us. The WG most recently discussed the matter in September; notes, and a link to the old UMA1 wiki area for holding "full matrix" testing results, are here: https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-20 If what we manage by June is similar self-organized testing, we could adapt the wiki to show those results. Or if we get more formal, we could show that. Can we please discuss in this thread and decide by Thursday so that Andi can get on with his agenda scheduling? Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New Identos entry on the Implementations page!
by Eve Maler 22 Feb '19

22 Feb '19

Thanks to Alec for updating the page, and congrats! https://kantarainitiative.org/confluence/display/uma/UMA+Implementations#UM… *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

The UMA2 Internet-Drafts have been submitted to IETF
by Eve Maler 22 Feb '19

22 Feb '19

https://mailarchive.ietf.org/arch/msg/oauth/r1mFPzQaXy322wSR3my5i1uCdXQ *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

4 4

UMA 2019-Feb-21 call
by Alec Laws 21 Feb '19

21 Feb '19

Hi all, my connection let me listen but not speak this morning :) Our view of UMA at IDENTOS is very similar to Adrian. If RSs serve a consistent/standards API (ie a FHIR profile) the client can easily consume a resource from any RS. We are advocating for UMA to healthcare entities in Canada because of the ecosystem & privacy benefits over plain Oauth 2.0/OIDC. Although RS's in Healthcare may not accept any AS (due to compliance/regulation/etc), UMA still allows many AS to define trusted ecosystems, and allow the RO to protect resources with any of them. Another major ecosystem benefit is the Clients loose coupling between the AS or RS (or both).The AS-RS must have a pre-existing relationship in most models(is this true? only after resource registration?) In our implementation the client has a few possible positions: 1. no previous knowledge of a specific AS or RS. Normal UMA. The RqP tells the client about a specific resource/RS. The RS pushes the client to the AS 2. knowledge of a specific RS. Normal UMA. The RS pushes the client to the AS 3. knowledge of a specific AS. This differs from core UMA and aligns closer to the resource indicators(?). The client requests a general resource from the AS, and the RqP binds to a specific RS during claims-gathering. The client must register with an AS for a 'resource type', and the AS must approve the scope. The client has no preference of RS/resource as long as they know the RqP is authorized access. This case also requires the AS to inform the client of the RS (we struggled with this an eventually just added a field to the token response.. bad) Regarding George's comment: "When a client uses an RPT to request a different resource, the AS should reject the RPT" Believe the AS may accept the RPT if it's under the same PAT. In the end, the RS must make the evaluation of the RPT's permissions against the requested resource Cheers, Alec Laws alec(a)identos.ca

2 1