feature: define process for devices to request access to a server

SignalK / specification

Signal K is a JSON-based format for storing and sharing marine data from different sources (e.g. nmea 0183, 2000, seatalk, etc)

Other

91 stars 68 forks source link

feature: define process for devices to request access to a server #505

Closed sbender9 closed 5 years ago

sbender9 commented 5 years ago

TODO:

[x] sync up with #508

tkurki commented 5 years ago

I am happy with this and would be ready to move forward with it.

fabdrol commented 5 years ago

I feel that this should be extended with the kind of access a client can request (i.e. read, read/write or admin - potentially with group modifiers)

tkurki commented 5 years ago

The problem that this PR is solving is how do you grant access to a device that has no practical input methods and you can not enter any kind of credentials to it.

I think we end up stalled if we try to specify the kind of access. For example:

node server has ACLs by path, not just a global read/readwrite - how do you specify that?
there is admin in the specification - what does that mean?

There is value in adding this to the spec as it is.

Issues and PRs are easy to open, hard to close.

sbender9 commented 5 years ago

I actually did intend this to be used for any kind of device. For example, WilhelmSK now supports requesting access this way.

For example, buddy can come on your boat. Try to connect with WilhelmSK and WilhelmSK can request access. You hit a button, done. No need to fuss with typing in username and password.

tkurki commented 5 years ago

Is this the my crew can hardly write use case?

fabdrol commented 5 years ago

What about this situation: I develop a native Signal K instrument. The instrument can display a certain number of values (i.e. paths), and needs only read access. The access request will be build into the software, i.e. hard-coded. I believe it makes sense if my screen only requests read access for the paths I need.

sbender9 commented 5 years ago

What about this situation: I develop a native Signal K instrument. The instrument can display a certain number of values (i.e. paths), and needs only read access. The access request will be build into the software, i.e. hard-coded. I believe it makes sense if my screen only requests read access for the paths I need.

My thought was that we could add this in the future. We currently don't have anything spec a providing path level permissions. Once we have that we could add something here.

fabdrol commented 5 years ago

My thought was that we could add this in the future. We currently don't have anything spec a providing path level permissions. Once we have that we could add something here

Alright, that makes sense. No more comments then ;)

sbender9 commented 5 years ago

@timmathews can you please review my responses above and let me know if this needs any more changes.

timmathews commented 5 years ago

The only thing we need to resolve for this, IMO is the mechanism for repeated access requests. And perhaps also, what they should do if access was previously granted and then revoked. That could happen when a client device is moved to another server (e.g. the device is sold or the server is replaced) or when someone manually revokes the grant.

tkurki commented 5 years ago

@timmathews please elaborate what problems you foresee (see my comment inline above)

As your comment sounds like possible additions I feel we can merge this as is and add more specific instructions if needed.