Hello Greg, Ondrej Tomcik :: KISTLER :: measure, analyze, inovate
From: Gregg Reynolds [mailto:[email protected]] Sent: Thursday, August 9, 2018 5:45 PM To: Tomcik Ondrej Cc: [email protected]; Scott King <[email protected]> ([email protected]); Max Kholmyansky ([email protected]); Kralik Jozef; Rafaj Peter Subject: Re: OCF Native Cloud 2.0 On Thu, Aug 9, 2018 at 6:48 AM, Ondrej Tomcik <[email protected]<mailto:[email protected]>> wrote: Dear IoTivity devs, Please be informed that the new Cloud 2.0 design concept is alive: https://wiki.iotivity.org/coapnativecloud Your comments are warmly welcome. Implementation is in progress. Obviously you put a lot of work into this, thanks. How does it handle third-party users? For example, Mom, Dad, kids, relatives, guests, all have different permissions, dynamically configurable. Current IoTivity implementation force you to use very specific user/device management model. What is bad. In this concept, AuthorizationService implementation is completely up to the user – user is the company who want to use the OCF Native Cloud. Of course we will provide sample AuthorizationService which communicates with the GitHub, but this one will be not used for production – I believe ☺. If you’re interested in multiple owners of the device, share the device with friends, and so on, you have to model this structure of users and management on yur own. OCF Native Cloud just defines contract, how it is communicating with the AuthorizationService. Meaning, the OCF Native Cloud will ask AuthorizationService, if the pending request (resource uri + device + token) is authorized or not. Token identifies the user who issued the request and together with resource uri + device id, AuthorizationService can clearly answer if the request is authorized or not. AuthorizationService should also emit events (changes which SID (user identifier – subject id) has access to which DID (DeviceId)), which are cached by the OCF Native Cloud so each user request is not triggering request to the AuthorizationService. Make sense? You can see it here: https://wiki.iotivity.org/_media/auth_1.png?cache=&w=900&h=699&tok=413462 Or read whole Authorization Bounded Context - https://wiki.iotivity.org/coapnativecloud#authorization_bounded_context And, important is this note: Each request session must be backed by an access token, so the OCF Native Cloud can authorize that request. In case of the OCF Servers / Clients, a TCP session must be backed by the access token and validated through the sign-up process. Each command issued by the OCF CoAP Gateway is then backed by the validated token. Gregg -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9839): https://lists.iotivity.org/g/iotivity-dev/message/9839 Mute This Topic: https://lists.iotivity.org/mt/24238274/21656 Group Owner: [email protected] Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
