)]}'
{"specs/proposed/rsa-key-existence-check.rst":[{"author":{"_account_id":9377,"name":"Sergey Slipushenko","email":"slipushenko@gmail.com","username":"sslypushenko"},"change_message_id":"2a56869bab2c4ac9d350b3d30d2d79f8834207e5","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  use a different key or delete the public key from his/her old account."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"* RefStack then associate the data to the user ID of the key owner by adding,"},{"line_number":39,"context_line":"  in the \"meta\" table, a \"meta_key\" named \"user\" with value being the \"_id\""},{"line_number":40,"context_line":"  from the \"user\" table."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a2fa921_18af8595","line":39,"updated":"2015-10-06 20:39:10.000000000","message":"I think \"openid\" field will be more suitable here, instated of \"_id\". It is unique and can\u0027t be changed.","commit_id":"dce192de5b1669bb73a0d3c8a359a115965a78e9"},{"author":{"_account_id":10526,"name":"Catherine Diep","email":"cdiep@us.ibm.com","username":"cdiep"},"change_message_id":"03eb4f29a427ea378a6b78fe60c6d3f1bae7a71e","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  use a different key or delete the public key from his/her old account."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"* RefStack then associate the data to the user ID of the key owner by adding,"},{"line_number":39,"context_line":"  in the \"meta\" table, a \"meta_key\" named \"user\" with value being the \"_id\""},{"line_number":40,"context_line":"  from the \"user\" table."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a2fa921_d3780e2e","line":39,"in_reply_to":"7a2fa921_18af8595","updated":"2015-10-06 22:30:09.000000000","message":"Hi Sergey, \n\nFor the user, I concur that we can use either \"openid\" or \"_id\".   The reason I use \"_id\" here is for the case, in the future, when the ownership of the data can be assigned to a \"company\" (which will be the _id field of the company table) or a product (which will be the _id field of the product table).  So to be consistent, _id field is used here.\n\nWe have not have all the data models iron out.  However,  I envision that the company table will have a \"group\" field.  Each \"group\" will have a number of user entities associated to it.  So if a test run is associated to a company then all users in this group potentially can access the data based the privileges dictated by the roles assigned to it.\n\nI can change this spec to use the \"openid\".  But, I just want to bounce this thinking back to you before any update.","commit_id":"dce192de5b1669bb73a0d3c8a359a115965a78e9"},{"author":{"_account_id":10526,"name":"Catherine Diep","email":"cdiep@us.ibm.com","username":"cdiep"},"change_message_id":"5b803b06b374134b3ea93fd5ea5e2a0093f02180","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  use a different key or delete the public key from his/her old account."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"* RefStack then associate the data to the user ID of the key owner by adding,"},{"line_number":39,"context_line":"  in the \"meta\" table, a \"meta_key\" named \"user\" with value being the \"_id\""},{"line_number":40,"context_line":"  from the \"user\" table."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a2fa921_3b0f9b89","line":39,"in_reply_to":"7a2fa921_bf4c0971","updated":"2015-10-08 21:46:10.000000000","message":"Done","commit_id":"dce192de5b1669bb73a0d3c8a359a115965a78e9"},{"author":{"_account_id":9377,"name":"Sergey Slipushenko","email":"slipushenko@gmail.com","username":"sslypushenko"},"change_message_id":"269947bbbddfe14ad0a7095e7f7f630fef7c9fac","unresolved":false,"context_lines":[{"line_number":36,"context_line":"  use a different key or delete the public key from his/her old account."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"* RefStack then associate the data to the user ID of the key owner by adding,"},{"line_number":39,"context_line":"  in the \"meta\" table, a \"meta_key\" named \"user\" with value being the \"_id\""},{"line_number":40,"context_line":"  from the \"user\" table."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a2fa921_bf4c0971","line":39,"in_reply_to":"7a2fa921_d3780e2e","updated":"2015-10-07 17:53:13.000000000","message":"_id is something what should be keep internal. Companies and products will have something like \"id\" instead of \"_id\". IMO \"openid\" is more suitable hete","commit_id":"dce192de5b1669bb73a0d3c8a359a115965a78e9"},{"author":{"_account_id":17700,"name":"David Liu","email":"david.liu@cn.ibm.com","username":"lzbj"},"change_message_id":"a654357f4191a5d4c4bb201aa5d49357469de89f","unresolved":false,"context_lines":[{"line_number":20,"context_line":"used to associated the test data to the users. And, there is no enforcement"},{"line_number":21,"context_line":"that the keys used for data uploading must exist in RefStack. In addition,"},{"line_number":22,"context_line":"for security reasons, keys are expected to be updated from time to time."},{"line_number":23,"context_line":"As a consiquence of the non-existing or updated keys, some data will be"},{"line_number":24,"context_line":"unaccessible."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a2fa921_f08b7dc1","line":23,"updated":"2015-10-08 06:35:43.000000000","message":"\u0027consiquence\u0027 one minor typo?","commit_id":"b12185a24f05ded4ff82b83f6f49bed305696e14"},{"author":{"_account_id":10526,"name":"Catherine Diep","email":"cdiep@us.ibm.com","username":"cdiep"},"change_message_id":"9ac0f94c86e396d31d838ed7a1bba1be5764e242","unresolved":false,"context_lines":[{"line_number":20,"context_line":"used to associated the test data to the users. And, there is no enforcement"},{"line_number":21,"context_line":"that the keys used for data uploading must exist in RefStack. In addition,"},{"line_number":22,"context_line":"for security reasons, keys are expected to be updated from time to time."},{"line_number":23,"context_line":"As a consiquence of the non-existing or updated keys, some data will be"},{"line_number":24,"context_line":"unaccessible."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a2fa921_4d062b1e","line":23,"in_reply_to":"7a2fa921_f08b7dc1","updated":"2015-10-08 21:45:36.000000000","message":"Done","commit_id":"b12185a24f05ded4ff82b83f6f49bed305696e14"}],"specs/rsa-key-existence-check.rst":[{"author":{"_account_id":9626,"name":"Paul Van Eck","email":"pvaneck@us.ibm.com","username":"pvaneck"},"change_message_id":"c329c4b70a7ee4d89761a847fd3c8d0119bc2a9a","unresolved":false,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Alternatives"},{"line_number":40,"context_line":"------------"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Open to other suggestions.  The key goal is to eliminate orphan data which are"},{"line_number":43,"context_line":"difficult to manage."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a1a9d01_6f755e96","line":41,"updated":"2015-09-28 18:44:51.000000000","message":"One alternative that may be simpler to implement:\n\nSince RefStack currently enforces a policy such that there are no duplicate public keys in the database, requiring an email will not be necessary as there is only one user that could have a specific public key. Checking the \u0027pubkeys\u0027 table should be quick as a hash of each public key is indexed for quick lookup. However, it is important to note that since no two users can have the same public key uploaded, key-pairs can not be shared, and if a user creates a new openstackid account, he/she  would have to use a different key or delete the public key from his/her old account. Regardless, this may be preferred policy.","commit_id":"d2ef6f6835402ed2d52b49063e6fc1dab2a507b3"},{"author":{"_account_id":9377,"name":"Sergey Slipushenko","email":"slipushenko@gmail.com","username":"sslypushenko"},"change_message_id":"3c9ac50a1867986b3d0a47721ba0db5e5c973242","unresolved":false,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Alternatives"},{"line_number":40,"context_line":"------------"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Open to other suggestions.  The key goal is to eliminate orphan data which are"},{"line_number":43,"context_line":"difficult to manage."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a1a9d01_c6de593d","line":41,"in_reply_to":"9a1a9d01_453492fa","updated":"2015-10-01 09:31:40.000000000","message":"IMO, Current state should be considered as temporary. So, there are 2 options here\nThe first one is that you mentioned before. It is easy way) I\u0027m ok with that. \n\nBut also we have second option) We can let users upload signed results as is and add some new ways how to interact with this results. For example, RefStack can provide sign-in as \"guest\" (suggested workflow: client generate one-off sign-in link from user\u0027s keypair, user opens it in browser, user becomes authorized as guest, guest can manage results uploaded with origin key). Also, general_admin can see signed, but not owned, test results with same key and manage them as single batch. I think there are other use cases where such behavior can be helpful.\n\nSo, my finial suggestion will be to leave upload signed results as is and add some hints in RefStack UI and client to help people follow the current workflow. Basically we just should mentioned that user should upload pubkey to see own uploaded test results.\n\nFor managing orphan data my suggestion is to set limited life time for it, maybe month should be okay.","commit_id":"d2ef6f6835402ed2d52b49063e6fc1dab2a507b3"},{"author":{"_account_id":10526,"name":"Catherine Diep","email":"cdiep@us.ibm.com","username":"cdiep"},"change_message_id":"5ca90606e1b25e148d12bf8134ee8a10c0d047aa","unresolved":false,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Alternatives"},{"line_number":40,"context_line":"------------"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Open to other suggestions.  The key goal is to eliminate orphan data which are"},{"line_number":43,"context_line":"difficult to manage."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a1a9d01_453492fa","line":41,"in_reply_to":"9a1a9d01_6f755e96","updated":"2015-09-30 20:11:56.000000000","message":"I would like to get Sergey\u0027s inputs on the requirement that keys are unique and not sharable.","commit_id":"d2ef6f6835402ed2d52b49063e6fc1dab2a507b3"},{"author":{"_account_id":17700,"name":"David Liu","email":"david.liu@cn.ibm.com","username":"lzbj"},"change_message_id":"d84f9d50218e8ca1178d82e91b814098e21d0d32","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Open to other suggestions.  The key goal is to eliminate orphan data which are"},{"line_number":43,"context_line":"difficult to manage."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"Data model impact"},{"line_number":47,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a1a9d01_3c26ab15","line":44,"updated":"2015-09-29 08:44:38.000000000","message":"Consider the extension flexibility in the future, maybe we could request more input from user, but internally use the hash for performance concern.\n\nIs it involve with the new vendor registration feature, besides, I noticed there is one bug https://bugs.launchpad.net/refstack/+bug/1498159, do we need to consider that?","commit_id":"d2ef6f6835402ed2d52b49063e6fc1dab2a507b3"}]}