<div dir="ltr"><h2 class="gmail-part" id="gmail-Attendees" style="color:rgb(0,0,0)">Attendees</h2><ul class="gmail-part" style="color:rgb(0,0,0)"><li class="gmail-">Gert Drapers</li><li class="gmail-">Alex Olivier</li><li class="gmail-">Alex Babaenu</li><li class="gmail-">Jeff Lombardo</li><li class="gmail-">Michiel Trimpe</li><li class="gmail-">Vladi Berger</li><li class="gmail-">Wei</li><li class="gmail-">Omri Gazitt</li><li class="gmail-">Dave Hyland</li><li class="gmail-"></li></ul><h2 class="gmail-part" id="gmail-Agenda" style="color:rgb(0,0,0)"><a class="gmail-anchor gmail-hidden-xs" href="#Agenda" title="Agenda"><span class="gmail-octicon gmail-octicon-link gmail-ph gmail-ph-link-simple-horizontal"></span></a>Agenda</h2><ul class="gmail-part" style="color:rgb(0,0,0)"><li class="gmail-">There have been a few working sessions focusing on the IDP interop scenario for the Gartner IAM conference. Let's review the latest changes and thanks to those who have attended these sessions</li><li class="gmail-">Pull request 367: addressing issues 358 and 359</li><li class="gmail-">Pull request 366: a second proposal regarding<span class="gmail-Apple-converted-space"> </span><code>offset</code></li></ul><h2 class="gmail-part" id="gmail-Notes" style="color:rgb(0,0,0)"><a class="gmail-anchor gmail-hidden-xs" href="#Notes" title="Notes"><span class="gmail-octicon gmail-octicon-link gmail-ph gmail-ph-link-simple-horizontal"></span></a>Notes</h2><h3 class="gmail-part" id="gmail-Gartner-interop" style="color:rgb(0,0,0)"><a class="gmail-anchor gmail-hidden-xs" href="#Gartner-interop" title="Gartner-interop"><span class="gmail-octicon gmail-octicon-link gmail-ph gmail-ph-link-simple-horizontal"></span></a>Gartner interop</h3><p class="gmail-part" style="color:rgb(0,0,0)">Interop spec:<span class="gmail-Apple-converted-space"> </span><a href="https://hackmd.io/1xG8MxATR_KsuYF7fXOVoA?view" target="_blank" rel="noopener">https://hackmd.io/1xG8MxATR_KsuYF7fXOVoA?view</a><br>Notes from Sep 10 call:</p><ul class="gmail-part gmail-in-view" style="color:rgb(0,0,0)"><li class="gmail-">Agreement that we will focus on "generic mechanism" for IdP as a PEP which calls a PDP for token issuance and token enrichment scenarios, as opposed to specific verticals like Open Banking. We will want to do the latter post v1</li><li class="gmail-">Agreement that using terms like "client" as the resource type is not advisable, since "client" has a specific semantic meaning in the context of the OAuth pantheon of specs, and we don't want to send the wrong impression that AuthZEN is somehow inserting itself in considerations such as client registration or tracking user consent, which are AS responsibilities</li><li class="gmail-">As a consequence, we made slight modifications to the payload - instead of "client-id" as a resource type, we chose "subscription". The implied scenario is that an external system is tracking user <-> subscription entitlements, and the IdP is making evaluation, evaluations, and search calls to determine whether a user has access to a specific subscription</li><li class="gmail-">Furthermore, we replaced the generic "claim" type with level (with specific levels of "bronze", "silver", "gold") to indicate the type of subscription a user may have.</li><li class="gmail-">We added another section parallel to evaluations which uses the resource search API to essentially ask the same question.</li></ul><p class="gmail-part gmail-in-view" style="color:rgb(0,0,0)">9/11 notes</p><ul class="gmail-part gmail-in-view" style="color:rgb(0,0,0)"><li class="gmail-">Demo app suggested architecture: pick and IDP and pick a PDP and display the resulting JSON token on the page</li><li class="gmail-">Per note above, decided against using 'client' as the resource and switched to 'subscription'</li><li class="gmail-">Token enrichment via search API was added in yesterday's meeting</li><li class="gmail-">JF: why is there a different action - issue vs. access? The group agreed to change all instances to 'issue'</li><li class="gmail-">JF: AS can issue several types of token. Will AuthZEN specify what kind of token or should this be left to the AS? OG: AuthZEN will not intrude on what the IDP/AS will issue</li><li class="gmail-">JF: What if there is a combination of id and access tokens will be issued? What opinion will AuthZEN have on this? OG: I don't think AuthZEN should have any impact on OAuth semantics, merely are offering a message exchane pattern. How OAuth uses this message exchange should be explored in a future profile.</li><li class="gmail-">JF: Another example is, if a token is to be issued for an example subscription but it must be encrypted - does AuthZEN propose to support that level of granularity? OG: Yes, it can be beyond only true/false flows.</li><li class="gmail-"></li></ul><p class="gmail-part gmail-in-view" style="color:rgb(0,0,0)">Next steps:</p><ul class="gmail-part gmail-in-view" style="color:rgb(0,0,0)"><li class="gmail-">Alex O will take lead on building demo app, starting with support of Auth0 as the prototype</li><li class="gmail-">Gerry will update the list of target IDPs to contact and identify who will reach out to each of them</li></ul><p class="gmail-part gmail-in-view" style="color:rgb(0,0,0)">Pagination</p><ul class="gmail-part gmail-in-view" style="color:rgb(0,0,0)"><li class="gmail-">Michiel covered his summary of proposed options</li><li class="gmail-">Remove pagination, include non-normative page object, keep current token pagination, combine token/offset/limit pagination, or support both types</li><li class="gmail-">GD: We should be clear about what implementations should do. Fine with having two options, but must be able to indicate in the request.</li><li class="gmail-">MT: Will start with offset and token, incorporating input from today's call to revise this PR</li></ul><p class="gmail-part gmail-in-view" style="color:rgb(0,0,0)">Other business</p><ul class="gmail-part gmail-in-view" style="color:rgb(0,0,0)"><li class="gmail-">All remaining issues have now been addressed and can be closed. Co-chairs will address this before the next weekly meeting.</li></ul></div>