Thanks for clarifications Ludwig, True, aud can be an array. We typically avoided this, hence, the omission.
For the case (2) to be used, there would be a single RS assumption indeed. This should be clearly said when we are proposing the option 2. Thanks for your response, --Cigdem On Fri, Jun 15, 2018 at 2:07 PM, Ludwig Seitz <[email protected]> wrote: > On 2018-06-14 14:09, Cigdem Sengul wrote: > >> Hello Ludwig, >> >> Again thank you for your comments. >> We are going through them and making several revisions to our draft. >> >> We want to discuss two of your comments further: >> >> (1) Our text: ”and the client is authorized to obtain a token for the >> indicated >> audience (e.g., topics) and scopes (e.g., publish/subscribe >> permissions)" >> >> Your comment: Note that the audience claim is typically used to identify >> the RS (so in this case the MQTT broker), while the scope is intended to >> identify both the resource (=topic) and the actions (=publish, subscribe). >> See this for how OAuth scopes are typically used: >> https://www.brandur.org/oauth-scope >> >> Our response: >> According to the draft-IETF-ace-oauth-authz-12, the audience of an access >> token can be a specific resource or one or many resource servers. >> >> So, we considered three ways to structure our tokens,given that a token >> can hold multiple scopes but only a single audience : >> >> (1) aud: RS >> >> scopes: underscoreseparated keywords representing<permission>_<topic>, >> e.g.,"publish_valve2012/temperature", "subscribe_/foo/+/bar", >> "subscribe_$SYS/#" >> >> (2) aud: resource, i.e., a topic in MQTT context >> >> scopes: permissions, i.e., publish and/or subscribe keywords >> >> (3) aud: permission, i.e., publish or subscribe >> scope: topics (i.e., resources), e.g., topic1 topic2 topic3 >> >> >> We think Options (1) and (2) fit the current text in the ace-oauthdraft, >> especially, when we consider this example: >> { >> "grant_type" : "client_credentials", >> "client_id" : "myclient", >> "client_secret" : "mysecret234", >> "aud" : "valve424", >> "scope" : "read", >> "cnf" : { >> "kid" : b64'6kg0dXJM13U' >> } >> >> If using option (1), we can choose to leave this as an "application >> specific convention". On the other hand, it could be useful to have >> this defined, because MQTT only allows publish & subscribe, and there are >> rules for the MQTT topic string. This would make ACE-savvy MQTT clients & >> servers generally more compatible/interoperable. >> >> Based on our option (2), these would be in MQTT - “aud”: “valve424”, >> “scope”: “subscribe” Note that, the multiple tokens trade-off we mention in >> our draft still exists for the core’s valve example too. This token does >> not help with reading “valve425”. >> >> >> Option (3)is more left-field proposition and does not align with the rest >> of the core draft. Though, it doeshavean efficiency advantage that a single >> token can permit access to multiple topics. >> >> Based on the ace-oauth draft, the first two options for token structure >> should be acceptable. We want to list both to avoid being too prescriptive >> about scope structures (as the option (1) dictates). >> >> > Note that 'the "aud" value is an array of case- > sensitive strings' (RFC7519 section 4.1.3), while scope is a "... list > of space-delimited, case-sensitive strings." (RFC6749 section 3.3), so you > could authorize access to several topics with different permissions in a > single token with all of the approaches you define above. > > Option 3 is clearly far off from the intended use of aud > (' the "aud" (audience) claim identifies the recipients that the JWT is > intended for.' ) > > In option 2 how do you avoid the use of an access token at a different > resource broker? > (For clarification: Say you have resource broker A and B who both serve > similarly named topics, but in entirely different locations, and who happen > to use the same AS.) > > > (2) >> >> Your comment: An example of how the CONNECT message could look like would >> be good. >> >> We think we need a bit of clarification about what kind of an example you >> have in mind. Our draft has a figure 2 that explains the different field an >> MQTT Connect packet will have. We could add an example in hex (MQTT being >> binary) but it wouldn't be as easy to read as the HTTP example. >> >> > > Perhaps hex-code with explanations under the different parts of it as in: > > 45FC 481A F56B 1234 A527 > Header Parameter1 Parameter2 Payload > > /Ludwig > > > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
