Agenda

Minutes

We are on track to deliver:

Test definitions - linting results #82 - to be close
Any idea/suggestion for next release?
- If no we can add a notice on the readme file: Schedule: onDemand - The project is currently stable, so meetings will be scheduled according to the needs of the working group participants

Test definitions - linting results #149 - to be close
Add MonitoredPeriod into the API Response if a Telco cannot show the date / data for for Privacy Reasons - #124
- Seems that we are aligned on the rationale to add this attribute. Now we are in the 'tech' design.
  If no objection I guess we can initialize a PR to discuss on code.
Request body is required but all properties are optional - #118 - the The discussion in in commonalities #247
Any other idea/suggestion for next release?

Test definitions - linting results #143: fixed - to be close
Convention for file names of API definition #142: fixed - to be close
Change "NUMBER_VERIFICATION.INVALID_TOKEN_CONTEXT" to "INVALID_TOKEN_CONTEXT" #141: fixed - to be close
Update UML Flow #116
- add sentences : "Note that the diagram shows just an example of a direct integration from developer's application and MNO's authserver and API, other scenarios of indirect integration via Aggregator/Channel Partner should also be considered. Specific authorization flows may apply, as defined by e.g. GSMA OGW"
- Not done
  - Decision: add it in the yaml - Ludovic Robert will check with Herbert how to do with the Release process.
Update Diagram with RFC 9101 to secure the /authorize endpoint - issue #93 & PR
- No progress but we keep it open for Spring25 meta-release
Integration to on device application (EAP-AKA) - issue #86
- Does this topic should be discussed in this WG (vs ICM)
  - Probably ICM is the right place to discuss this - Ludovic Robert will interact with ICM on behalf of our group.
- What are our plans on this topic for NV workgroup?
Any other idea/suggestion for next release?
Let's open a discussion on the usage of the id token in this API. Huub Appelboom provided a rational for this id: This could very useful to monitor when a phone number has been recycled to another user (as we we fill in the user id).