Hello Jim, > > > > When topic subscriptions are protected, the Broker can choose to do two > things: > > 1) Allow the subscription but internally subscribe the clients to > sport/basketball and sport/tennis only. > > or > > 2) Reject the subscription and the client needs to ask for subscriptions > that are a subset or equal to their permission strings. So the client > specifically needs to ask for publish_sport/tennis and > publish_sport/basketball matching its scope strings. But then scope > parameter cannot be optional and must be included in the AS response. > > or > > 3) Allow the subscription, when a new level is added, check the > permissions of all active subscribers, send DISCONNECT if the current > permissions do not apply to the new hierarchy. > > > > 1 would need to be again signalled to the client, 2 might be too > restrictive, and 3 may introduce a processing load if things are changing > all the time (which I do not expect). > > Leaning towards 3... Any thoughts? > > > > [JLS] My first thought was to run and hide. I think you have the scope > strings setup wrong, they all should be “subscribe_” not “publish_” as a > client is never going to ask to publish with a wildcard (MQTT-3.3.2-2). > I would far prefer that the answer be 2 rather than 1 and I think that 3 > is right out. >
Gosh... Don't know why I switched to publish... Sorry for any pain caused! > > > For 3 you are saying we are going to subscribe you, and then potentially > disconnect you at a later time for something you never heard about. I > don’t really care about 1, only because there is no way to communicate this > information back to the client that one is changing the set of > subscriptions that was requested. > Ah, I see your interpretation- I saw the subscription request for subscribe_topic/+ and subscribe_topic/# as a request from the subscriber saying "send me anything under x" (depending on +/# restrictions). So, they may not know all the matching subtopics anyway. If the permissions are including the wildcards and cover the request, no problem. But, if they don't but the combination of a subset of permissions do at the current state (i.e., subscribe_sport/basketball + subscribe_sport/tennis = subscribe_sport/+), I wondered whether the RS may want to accept this request. However, if it registers this subscription as subscribe_sport/+, it is not future proof for any changes to that level and client would be lacking the appropriate permissions - which should lead to a disconnect. > > > I am not sure what you are requesting in terms of returning the scope > parameter. The current OAuth specification states that if the > Authorization server returns a token that contains a different scope that > the one requested by the client, then it is required to return the modified > scope to the client. Is that what you are looking for. > Thanks, I was not sure that was a MUST, and I should have read the RFC more carefully. (Possibly I got confused with another spec out of IETF, where the client may not have the final info on the scope.) Then 2 would definitely work and is much simpler. I was thinking it may be restricting. But, it's best to avoid the complexity of additional checks on combinations of permissions to see if the request can be satisfied. Thanks for your feedback. --Cigdem > > > Jim > > > > > > --Cigdem > > > > > > > > > > > > Jim > > > > > > --Cigdem > > > Jim > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
