-----Original Message----- From: Marco Tiloca <marco.til...@ri.se> Sent: Monday, February 24, 2020 2:14 PM To: Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-key-groupcomm-osc...@ietf.org Cc: 'Ace Wg' <ace@ietf.org> Subject: Re: Scope question
Hi Jim, On 2020-02-24 19:02, Jim Schaad wrote: > I was starting to code up the encoding of scope and wanted to clarify > what the encoding is. > > The text appears to say that the encoding is: > > scope = [ groupId: tstr, ?[* role : any ]] > > I was expecting this to be more along the lines of > > scope = [ + scope_item ] > scopeItem = [ groupId: tstr, ?[* role : any ]] > > This would allow for more than one group to be identified in a single > token which I think is important given some of the statements about > only having a single token for a client. This does not solve the > resource server having multiple audiences but that is fine. ==>MT At the January interim, we mentioned a multi group/topic scope as next step. The format you suggest above is essentially the one we also had in mind. This should be firstly defined in the ace-key-groupcomm document. This should be just fine for the Token request/response and the Access Token itself. Then I am thinking of what happens next. In a general case, in each of the specified groups a different signature algorithm (etc.) is used. Then, in the 2.01 response from /authz-info , we would have 'sign_info' also as an array of arrays and 'pub_key_enc' as an array (unless the very same configuration applies for each scopeItem above). Same goes for 'rsnonce' becoming an array. The order of such arrays' elements is the same as for the scopeItems in the 'scope' claim. <== [JLS] I am having some problems with thinking that this is a good idea. The only reason to have different signing keys is to keep the different signature keys isolated in terms of correlation. If this is the case then adding a situation where we are going to share this information with a specific entity seems to be a bad idea. I would think that if the signing keys are going to be separate then that should be true all of the back as far as possible. This would mean that, if possible, that even the AS should not know that the different signing keys are associated with the same entity. Jim > > I am unsure if it makes sense to allow for the array to be removed for > scope in the second example in the event that only one group is > specified. One byte saved at the expense of more code. ==>MT I think it makes sense to avoid that byte, and essentially revert to the original scope format when only one group is specified. <== Best, /Marco > > Jim > > -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
