kwartzlab / kos-base

KwartzlabOS
4 stars 1 forks source link

Create kiosk function to identify keys #51

Closed azend closed 2 months ago

azend commented 5 months ago

Occasionally keyfobs may be found at Kwartzlab left by a member but contain no means of identification or visible trace of ownership. It would be useful if there was a means to identify existing tags linked in kOS to return lost items to their rightful owners.

Given we already have kiosks available inside the space and already configured with tag readers, they could be used to identify key ownership by reading key data and seeing what member it links to in the kOS database.

It may be possible that creating a means to identify key ownership could further the possibility for malicious use within the lab. For this reason it may be beneficial to secure this function to users with the can:manage-keys permission. Further discussion about this should be escalated to business policy level decision makers.

readysteadywhoa commented 5 months ago

Considering the kiosk already identifies the key if active (it will bring up the kiosk menu with 'Hello ') I don't think an ID function would be any more of a security concern then the current behaviour. Additionally it would be useful to identify inactive keys, since the only way to view those is to try and assign the key to someone else through the kiosk (this will bring up a 'key is already assigned to , reassign?' prompt).

On Mon, Jun 17, 2024 at 3:29 PM Verdi R-D @.***> wrote:

Occasionally keyfobs may be found at Kwartzlab left by a member but contain no means of identification or visible trace of ownership. It would be useful if there was a means to identify existing tags linked in kOS to return lost items to their rightful owners.

Given we already have kiosks available inside the space and already configured with tag readers, they could be used to identify key ownership by reading key data and seeing what member it links to in the kOS database.

It may be possible that creating a means to identify key ownership could further the possibility for malicious use within the lab. For this reason it may be beneficial to secure this function to users with the can:manage-keys permission. Further discussion about this should be escalated to business policy level decision makers.

— Reply to this email directly, view it on GitHub https://github.com/kwartzlab/kos-base/issues/51, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJXCSA24D5FPCRQJTFFFSDZH42JJAVCNFSM6AAAAABJOTKY2SVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM2TQMBZGMZDSNY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

azend commented 2 months ago

When I opened this issue, I didn't remember that the kiosk already greets a provided key with the linked member name. If the kiosk already performs this function, I'm not sure there's much benefit to providing an additional utility that duplicates this function.