[Openid-specs-authzen] Meeting notes from Sep 11

[gerry gebel]

Attendees

   - Gert Drapers
   - Alex Olivier
   - Alex Babaenu
   - Jeff Lombardo
   - Michiel Trimpe
   - Vladi Berger
   - Wei
   - Omri Gazitt
   - Dave Hyland
   -

<#Agenda>Agenda

   - 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
   - Pull request 367: addressing issues 358 and 359
   - Pull request 366: a second proposal regarding offset

<#Notes>Notes <#Gartner-interop>Gartner interop

Interop spec: https://hackmd.io/1xG8MxATR_KsuYF7fXOVoA?view
Notes from Sep 10 call:

   - 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
   - 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
   - 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
   - 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.
   - We added another section parallel to evaluations which uses the
   resource search API to essentially ask the same question.

9/11 notes

   - Demo app suggested architecture: pick and IDP and pick a PDP and
   display the resulting JSON token on the page
   - Per note above, decided against using 'client' as the resource and
   switched to 'subscription'
   - Token enrichment via search API was added in yesterday's meeting
   - JF: why is there a different action - issue vs. access? The group
   agreed to change all instances to 'issue'
   - 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
   - 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.
   - 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.
   -

Next steps:

   - Alex O will take lead on building demo app, starting with support of
   Auth0 as the prototype
   - Gerry will update the list of target IDPs to contact and identify who
   will reach out to each of them

Pagination

   - Michiel covered his summary of proposed options
   - Remove pagination, include non-normative page object, keep current
   token pagination, combine token/offset/limit pagination, or support both
   types
   - GD: We should be clear about what implementations should do. Fine with
   having two options, but must be able to indicate in the request.
   - MT: Will start with offset and token, incorporating input from today's
   call to revise this PR

Other business

   - All remaining issues have now been addressed and can be closed.
   Co-chairs will address this before the next weekly meeting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250911/253492c2/attachment.htm>