15:03:15 <dmendiza[m]> #startmeeting keystone
15:03:15 <opendevmeet> Meeting started Tue Jun 21 15:03:15 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:03:15 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:15 <opendevmeet> The meeting name has been set to 'keystone'
15:03:52 <dmendiza[m]> #topic Roll Call
15:05:22 <knikolla> o/
15:05:53 <dmendiza[m]> Hi knikolla !
15:06:13 <h_asahina> o/
15:08:48 <dmendiza[m]> OK, let's get started
15:08:55 <dmendiza[m]> #topic Review Past Meeting Action Items
15:08:57 <dmendiza[m]> #link https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-06-14-15.04.html
15:09:14 <dmendiza[m]> > dmendiza[m] to try to run keystone from a fresh clone
15:09:17 <dmendiza[m]> I did not do this
15:09:24 * dmendiza[m] kicks can down the road
15:09:40 <dmendiza[m]> #action dmendiza[m] to try to run keystone from a fresh clone
15:15:48 <dmendiza[m]> #topic Liaison Update
15:15:57 <dmendiza[m]> I don't have any 😅
15:16:03 <dmendiza[m]> #topic OAuth 2.0
15:16:11 <dmendiza[m]> h_asahina: any updates for this week?
15:17:23 <h_asahina> it's not update, but I'd like to discuss the contents of Spec.
15:17:30 <dmendiza[m]> sure
15:17:34 <h_asahina> thanks.
15:18:21 <h_asahina> As I described in the spec, We're going to implement RFC8705 in Zed.
15:19:47 <h_asahina> As you may know, RFC8705 is a kind of extension of OAuth2.0 which binds the client certificates to the OAuth2.0 access tokens to verify the identity of clients.
15:20:25 <h_asahina> The problem is to use rfc8705, we need to store the client certificates to DB in some way.
15:21:30 <h_asahina> Since we used the application credentials table for OAuth2.0 client management in Yoga, we can't change the DB schema easily.
15:22:36 <h_asahina> So I suggested that to simply store a client certificate as a secret of the application credentials as a workaround.
15:23:04 <h_asahina> Do you think it's possible?
15:23:41 <h_asahina> or do you have any other good idea other than adding a new table for the OAuth2.0 client management
15:24:40 <dmendiza[m]> Hmmm....  why are you trying to avoid schema changes?
15:25:47 <h_asahina> because I thought changing the application credentials table for OAuth2.0 is not good idea.
15:26:10 <h_asahina> it will be unrelated changes for the application credentials
15:27:12 <dmendiza[m]> Right, but we could add a new table for OAuth2.0
15:27:39 <dmendiza[m]> I can think of a few ways to solve this:
15:27:49 <dmendiza[m]> * save certs in the database by creating a new table
15:28:15 <dmendiza[m]> * save certs locally in the file system (this is probably a bad idea if we run multiple api nodes)
15:28:20 <dmendiza[m]> * save certs in etcd
15:28:26 <dmendiza[m]> * save certs in barbican
15:29:16 <h_asahina> `save certs in barbican`. This might be better.
15:29:23 <knikolla> i don't think we should use application credentials for this in particular.
15:30:46 <knikolla> as this is a different type of credential from a client/secret or username/password.
15:31:27 <knikolla> so we need to change the API to allow to associate a user with a certificate
15:32:08 <h_asahina> I understand that we shouldn't use application credentials for this, but if we add a new table, we need to add new OAuth2.0 API to manage the client.
15:34:10 <h_asahina> We have to do that because we're using the applicaton credentials API for client management now. is that ok to add new APIs for this purpose?
15:34:54 <knikolla> it's less about the database, and more about the API. I'm okay with associating some PKI with a user and then using that to authenticate.
15:35:13 <knikolla> I don't want keystone to have APIs specific to client management, but credential management is okay I think.
15:36:09 <knikolla> And requiring Barbican for this seems fair.
15:36:41 <h_asahina> I agree about Barbican.
15:37:22 <h_asahina> okey. I wrote the scenario for adding a new table in Alternatives block of Spec. Cloud you check that later?
15:38:47 <knikolla> yes, thanks!
15:39:10 <h_asahina> thanks. but, sorry, one more question.
15:39:54 <knikolla> keystone does have an API for associating credentials with a user https://docs.openstack.org/api-ref/identity/v3/#credentials, but i'm not familiar with it and it perhaps might be something we can use here.
15:40:44 <h_asahina> thanks
15:41:06 <h_asahina> I think Keystone also has authentication using PKI: https://docs.openstack.org/keystone/pike/advanced-topics/configure_tokenless_x509.html
15:42:48 <h_asahina> do you think we use it for this purpose. I don't understand the details of it.
15:43:08 <h_asahina> /purpose./purpose?/
15:44:10 <knikolla> Correct. I'm not very familiar with it, however my understanding is that it can only work for certificates issued by trusted authorities, rather than allowing a user to upload their own self-signed certificate
15:44:29 <knikolla> Depending on your use case, it may work.
15:46:12 <h_asahina> > only work for certificates by trusted authorities. If so, it might be not suitable.
15:47:06 <h_asahina> thanks. I felt the use case of tokenless_x509 is a little bit different, so I'd like to confirm. that's why I asked.
15:47:49 <h_asahina> I'll check the Credentials API and update the Spec if necessary.
15:48:02 <dmendiza[m]> Thanks, h_asahina
15:48:25 <dmendiza[m]> #topic Gate inherited assignments from parent (bbobrov)
15:48:31 <dmendiza[m]> bbobrov: around?
15:54:39 <dmendiza[m]> I guess not
15:54:49 <dmendiza[m]> and that's almost the end of the hour
15:55:00 <dmendiza[m]> Thanks for joining, y'all
15:55:03 <dmendiza[m]> #endmeeting