Community Attendees:

Axel Nennker Ming Hui Foo Jan Friman Tanja de Groot Eric Murray Jesús Peñasebastien dewet Diego González Martínez Juan Fabio García, Guido García

Community Attendees:

LF Staff:

Identity and Consent Management meeting

Agenda

  1. Welcome

    1. Please add or remove yourself from the attendees list. New template for Minutes created by Casey Cain 

  2. Issues and PRs. Priority discussions (most active issues and/or dependencies for release v0.2):

Welcome

Discussion on issue "More than one "purpose" in an authorization request. #140"

elisabeth.mueller@ericsson.com 

Discussion on "Camara OIDC profile #121"

Axel Nennker 

Current status:


Axel gave a recap of the latest discussions and what resolved.

The "purpose" issue is still open. Orange stated that a new parameter "purpose" would be hard to get accepted by implementers as implementers like to implement standards.

Jesús Peña first clarifies with Orange that there seem to be two separate discussions around purpose (issue #140). One is whether to use "purpose" request params (option 1) or scope prefixes (option 2). And the other is whether or not to initially consider more than one purpose in the same authorization request. Orange (sebastien dewet) clarifies that they are against using "purpose" request param as they understand it as a non-standard option. However, Orange/Sebastien confirm that they are fine with the one purpose limit. However, Sebastien also mention that in his opinion we will tend to have more than one purpose per authorisation request.

Telefónica then suggested during the call to go with option 1 (use a separate "purpose" request param and only one purpose per authorisation request) for now, given the existing requirements, and if more complex scenarios arise in the future, we can think about other solutions like RAR (OAuth 2.0 Rich Authorisation Requests - https://datatracker.ietf.org/doc/html/rfc9396).

Jesús Peña /TEF mentions that if the WG defines the possibility to declare more than one purpose (for example by means of scope prefixes as in Option 2), we have to avoid to request same technical scope for different purposes.

After a long discussion that took the whole time of the meeting about use case and mostly about different purposes for the same technical scope... Jesús Peña suggested as an option that if we don't manage to get an agreement on the "purpose" issue, we could remove this section for the moment in order to unlock PR #121 and all the related issues it closes. And then create a new PR to include a finer agreement on the purpose solution. But based on past WG experience, it may take a long time and further iterations to finally agree on the purpose solution, and it may be better not to block PR #121 until then.

From Axel Nennker  perspective removing the section on "purpose" would mean that the previous spec (v0.1) would be in effect. Jesús Peña says that it could just be temporary and before the next WG release is created.

Regarding proposed use of Rich Authorization Requests to specify purpose. Axel said that RAR could probably do the trick but the RAR is too generic to be use full. While RAR is a standard, all the details are left to the reader. It is not obvious how to request purpose in an RAR request.

Axel suggested to take the 0.1 text on "purpose" and with the results of the discussion improve the former text.

Axel proposed new text and asked participants to review it. If this text does not cut it or can not shaped to agreement, we are going to have a special ICM meeting next week Wednesday solely for this topic.

Telefónica say that they will need time to internally validate the new text and changes included in the profile during the call itself, as this new alternative is documented in just a few minutes and we may be missing something important. 


After the meeting Axel created a new document with an example for specifying purpose in scope.


Closing Remarks

Axel kindly asked participants to comment on issues and to review PRs and most importantly contribute text changes to PR. WGs thrive only if members become participants. So, again please participate. Please comment and review.

AoB