Hi Jim, On 2020-02-25 06:17, Jim Schaad wrote: > > -----Original Message----- > From: Marco Tiloca <[email protected]> > Sent: Monday, February 24, 2020 2:14 PM > To: Jim Schaad <[email protected]>; > [email protected] > Cc: 'Ace Wg' <[email protected]> > 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.
==>MT I see your point, that holds regardless the simple or structured scope. So far, we have considered a client possibly providing different public keys to be able to join different types of groups, i.e. using different signature algorithms, under the same GM, hence requiring different public keys to correctly work. We haven't thought of a client interested in isolating its signature keys, which would of course fail by concentrating multiple public keys on the same entity. Let's build on limiting a client to have at most one public key under a same GM. Then the following should happen. 1) It's still possible for the GM to have different types of groups, i.e. using different signature algorithms. 2) The client cannot (ever?) join groups of different types, as that would require different public keys to be provided to the GM. 3) If an administrator changes the signature algorithm of one group, the same change should be enforced for consistency to the other groups of the same kind, in the interest of their current members. Those members would have to upload a new working public key, hence ending up exposing a second one anyway. On the good side, that would simplify the public key handling and caching at the GM in [1] :-) [1] https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#section-5 <== Best, /Marco > > 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 > > > -- 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
