15:00:13 <dmendiza[m]> #startmeeting keystone
15:00:13 <opendevmeet> Meeting started Tue Jan 11 15:00:13 2022 UTC and is due to finish in 60 minutes.  The chair is dmendiza[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:13 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:13 <opendevmeet> The meeting name has been set to 'keystone'
15:00:29 <dmendiza[m]> #topic Roll Call
15:00:38 <dmendiza[m]> Courtesy ping for ayoung, bbobrov, crisloma, d34dh0r53, dpar, dstanek, gagehugo, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, spilla, ruan_he, wxy, sonuk, vishakha,Ajay, rafaelweingartner, xek
15:01:01 <knikolla> o/
15:01:32 <d34dh0r53> o/
15:02:29 <dmendiza[m]> Hi y'all!
15:02:42 * dmendiza[m] is the dev formerly known as redrobot
15:02:47 <dmendiza[m]> in case anyone is wondering
15:02:58 <dmendiza[m]> Let's get started.
15:03:06 <dmendiza[m]> #topic Review Last Year's Action Items
15:03:20 <dmendiza[m]> #link https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-12-07-15.04.html
15:03:24 <dmendiza[m]> We didn't have any
15:03:32 <dmendiza[m]> #topic Liaison Updates
15:03:38 <dmendiza[m]> knikolla: any updates for us?
15:03:56 <knikolla> No updates. Still getting back in the rhythm of things after PTO
15:04:05 <dmendiza[m]> Same
15:04:14 <dmendiza[m]> Okay, let's move on
15:04:18 <dmendiza[m]> #topic Specs
15:04:41 <dmendiza[m]> Let's start with OAuth 2.0 spec
15:04:42 <dmendiza[m]> #link https://review.opendev.org/c/openstack/keystone-specs/+/813152
15:05:03 <dmendiza[m]> Looks like there's a new patch up for review
15:05:09 <dmendiza[m]> I have not had a chance to look at it yet
15:05:14 <dmendiza[m]> (I just came back from PTO yesterday)
15:06:46 <knikolla> I haven’t had a chance to review the new patchset either.
15:07:12 <h_asahina> o/
15:07:31 <dmendiza[m]> Do we have a spec freeze?  I see Cinder and Manila have Spec freezes in R-15 https://releases.openstack.org/yoga/schedule.html
15:07:33 <h_asahina> I'd like to discuss bout that update later
15:08:18 <dmendiza[m]> hi h_asahina !
15:08:36 <h_asahina> hi
15:09:29 <dmendiza[m]> Now would be a good time for updates if you have any
15:09:33 <dmendiza[m]> since OAuth is the current topic
15:09:52 <h_asahina> okey
15:10:17 <h_asahina> Today I'd like to talk bout four topics as I wrote in the etherpad
15:10:50 <h_asahina> The first three topics are not heavy, which are basically confirmations.
15:11:03 <h_asahina> and the last topic is discussion.
15:11:41 <h_asahina> The fist topic is about `scope` function.
15:12:31 <h_asahina> We'd like to omit the scope function of OAuth2.0 in Yoga release.
15:13:32 <h_asahina> The reason behind this is that the scope definition in OAuth2.0 and that in Application credentials are different and thus we have to further discuss how to map the OAuth scope to Application credentials scope.
15:14:25 <h_asahina> but we don't have enough time to do that. So, we've dicided to omit it. If you feel any concern please tell me.
15:15:15 <h_asahina> This is the first topic. any comments?
15:15:57 <dmendiza[m]> Seems reasonable to reduce the scope (no pun intended) of the implementation for Yoga
15:16:27 <knikolla> if 'scope' is an optional word in an authentication request for oauth 2.0 client credentials, sure.
15:16:49 <knikolla> i'll have to reread the spec. my memory is rusty from before the new year's break.
15:17:17 <h_asahina> Yes it's an optional parameter. :knikolla.
15:17:57 <knikolla> ok, works for me then.
15:19:00 <h_asahina> thanks, I've already removed scope from the spec.
15:19:43 <h_asahina> Please put a comment on the spec if you find a problem on the new version.
15:20:08 <h_asahina> So, I'll move on to the next topic.
15:20:46 <h_asahina> The second topic is about the permission.
15:22:24 <h_asahina> As the OAuth2.0 APIs uses Application credential APIs as its backend, users have to get permissions to access both OAuth2.0 APIs and Application credential APIs. This is the straight forward way to manage the users' permission for the OAuth2.0 that I thought.
15:22:57 <h_asahina> Do you agree with this?
15:23:25 <h_asahina> If you have any other options, please kindly tell me.
15:23:44 <knikolla> yeah, the application credentials are created through the application credential api. and authenticating with them will use the oauth 2.0 api, so makes sense.
15:24:34 <h_asahina> Thanks.
15:25:31 <h_asahina> but please note that we are going to create a new application credential automatically when an OAuth2.0 client is created.
15:26:17 <knikolla> can you elaborate on that? why does an oauth 2.0 client need to be created and how is that different from an application credential?
15:27:46 <h_asahina> This is beacuse the OAuth2.0 client has some different attributes like `token_endpoint_auth_method`, `grant_type`, etc, which are not available on the application credentials.
15:28:09 <knikolla> can you describe what those attributes mean and why they are necessary?
15:30:00 <h_asahina> okey. These attributes are necessary to distinguish the grant type basically that is how a client get an OAuth2.0 token.
15:30:34 <knikolla> but the only grant type that we are supporting is client_credentials
15:30:41 <h_asahina> yes
15:31:17 <h_asahina> If we'll not extend that in the future, we can fix this to client_credentials
15:31:57 <knikolla> are there any reasons not to treat all application credentials as clients?
15:33:00 <knikolla> as in, if an application credentials is created, that can be used to authenticate through the oauth 2.0 api. without the need for new data models.
15:33:39 <h_asahina> If we make OAuth2.0 general, we should create a new API.
15:33:40 <d34dh0r53> go 55
15:33:46 <d34dh0r53> oops, sorry
15:34:33 <h_asahina> that what I thought.
15:34:52 <h_asahina> but maybe you're right.
15:35:13 <knikolla> if we start implementing more grant types, yes. But that requires further thought in how to map the attributes between the two.
15:36:02 <knikolla> especially with regards to how to convey projects and roles, for which oauth 2.0 is very vague about.
15:36:21 <knikolla> application credentials already carry all the authorization information that we need and map very cleanly to client credentials.
15:36:48 <h_asahina> I see. That's true. We don't have to implement redundant APIs for the future.
15:36:50 <knikolla> so, in my opinion, for now it's sufficient to just provide an authentication API for application credentials that looks like Oauth 2.0.
15:37:35 <h_asahina> Got it. I'll discuss it with our development team.
15:38:10 <knikolla> Thanks. I'm just trying to reduce the attack surface that implementing a new authentication type introduces.
15:38:27 <knikolla> But if there are obvious benefits to going all in and implementing more general oauth 2.0, i'm open to it.
15:39:01 <h_asahina> Thanks. I basically agree with your suggestion.
15:39:01 <knikolla> Though I think we should be conservative about such an approach given out very small team size.
15:39:23 <knikolla> And I'd prefer starting with adding support for oidc in keystonemiddleware and bypassing keystone entirely, haha.
15:39:29 <knikolla> for that thing in specific.
15:40:28 <h_asahina> Actually, it's benefit for us as the implementation gets easier.
15:41:33 <h_asahina> okey, thanks. I'd like to move on to the next.
15:42:12 <h_asahina> The third topic is the API endpoint.
15:42:54 <h_asahina> In the current spec, I wrote `/identity/v3/auth/OS-OAUTH2/clients` as an endpoint URL for the OAuth2.0. is it okey?
15:43:44 <h_asahina> other options can be i)  `/identity/v3/auth/OS-OAUTH2/<user_id>/clients` ii) `/identity/v3/users/{user_id}/OS-AUTH2/clients`.
15:44:34 <h_asahina> Could you give me your opinion as it affects to keystone users.
15:44:46 <knikolla> For the authentication request?
15:45:20 <h_asahina> Ah, sorry, a token request considering the today's discussion.
15:45:28 <dmendiza[m]> What is the benefit of having the user_id in the URL?  Is it not present in the body of the request?
15:45:43 <dmendiza[m]> or can it not be inferred from the body of the request?
15:46:35 <h_asahina> I thought body doesn't contain user_id but we can obtain it from X-Auth-Token at least.
15:46:55 <h_asahina> The reason why we put user_id is just following the URL of Application credentials.
15:47:01 <knikolla> That would have been for the CRUD of OAuth 2.0 requests, at this point we just need to decide on what we'll be the `token_endpoint` for OAuth 2.0.
15:47:25 <knikolla> As that's the only API that is needed after today's discussion.
15:48:26 <h_asahina> Yes indeed.
15:48:40 <knikolla> Part of me thinks it shouldn't be in /v3 at all, as this is part of the OAuth 2.0 API, not the OpenStack Identity v3 API.
15:49:18 <knikolla> But that might be troublesome given the auth_url usually including v3 in the path.
15:49:36 <knikolla> But in this case it wouldn't be openstack clients authenticating, so maybe it doesn't matter.
15:52:08 <h_asahina> but we'll implement token endpoint inside the keystone as well as the existing OAuth1.0 APIs. In this case, it's still better to remove v3?
15:53:08 <h_asahina> https://docs.openstack.org/api-ref/identity/v3-ext/#os-oauth1-api
15:53:47 <knikolla> perhaps /v3/auth/tokens, then. since oauth1.0 is using that as well?
15:54:43 <knikolla> or v3/OS-AUTH2/tokens
15:54:50 <knikolla> or v3/oidc/tokens
15:55:10 <knikolla> I'm don't have a strong opinion.
15:55:19 <h_asahina> /v3/auth/tokens or v3/OS-AUTH2/tokens sound reasonable.
15:55:48 <h_asahina> If it doesn't serious problem I'll choose from one of them.
15:55:58 <h_asahina> it isn't
15:56:07 <dmendiza[m]> 5 minute warning
15:56:29 <knikolla> I don't feel strongly about any of them.
15:56:53 <h_asahina> okey.
15:57:34 <dmendiza[m]> We're almost out of time.
15:58:16 <dmendiza[m]> h_asahina: maybe we can continue this next week, or after the meeting.
15:58:16 <h_asahina> got it. we don't have to discuss the last topic as it is soleved by today's discussion.
15:58:26 <dmendiza[m]> Great
15:58:26 <knikolla> cool!
15:58:39 <dmendiza[m]> Thanks for joining, everyone!
15:58:41 <d34dh0r53> I have something really quick, I'd like to host another reviewathon this Friday, the 14th.  Please let me know if you're interested
15:58:43 <dmendiza[m]> #endmeeting