Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Typo corrections. Agree on Axel's changes to address my comments

Telefónica's proposal was to try to focus now in a v0.2.0 profile version including existing agreements and required clarifications on top of them. And complete this in PR #121 using DT's PR as a reference. TEF PR could be closed (or put in draft for the record). And then non previously discussed topics (like us DPoP, etc...) or mid-term solutions pending to be agreed (basically the purpose one) to be discussed in dedicated issues and considered for a next OIDC profile version (v0.3.0). We said that discussions like the purpose one can take a long time (like it happens in the past for for v0.1.0 agreement) and it does not make sense to block current PR until all these discussions are finished.

Identity and Consent Management meeting

...

Axel said that we are having good discussions and comments on #121. There is good progress. Some topics should be tackled in their own issues referencing #121. Our work should concentrate on one profile and TEF agreed that the most support seems to be for the DT proposal.


Guido Garcia's proposed focussing focusing now on a v0.2.0 profile version including existing agreements and required clarifications on top of them. And complete this in PR #121 using DT's PR as a reference. TEF PR could be closed (or put in draft for the record). And then non previously discussed topics (like us DPoP, etc...) or mid-term solutions pending to be agreed (basically the purpose one) to be discussed in dedicated issues and considered for a next OIDC profile version (v0.3.0). TEF said that discussions like the purpose one can take a long time (like it happens in the past for for v0.1.0 agreement) and it does not make sense to block current PR until all these discussions are finished.

...

On the other hand, regarding the proposed offline access text for the OIDC profile in the PR, Jesús Peña García-Oliva  said that he is fine with this text, except for the rules copied from the OIDC standard. In the case of CAMARA, authorization code is not the only flow to support. For example, offline_access must also be allowed for the CIBA flow. And I he also mentioned that there was no requirement on the prompt value or application type to use the offline_access scope to request a refresh token to cover Opengateway off-net scenarios to access CAMARA service APIs.

...