Subject: [Ace] Scope question

From: Jim Schaad <[email-masked]>
Date: Mon, 24 Feb 2020 10:02:17 -0800

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.

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.

Jim

---

From: Marco Tiloca <[email-masked]>
Date: Mon, 24 Feb 2020 22:13:49 +0000

Hi Jim,

> 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.
<==

> 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

-- 
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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 24 Feb 2020 21:17:18 -0800

-----Original Message-----
From: Marco Tiloca <[email-masked]> 
Sent: Monday, February 24, 2020 2:14 PM
To: Jim Schaad <[email-masked]>; [email-masked]
Cc: 'Ace Wg' <[email-masked]>
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.
>
> 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

--
Marco Tiloca
Ph.D., Senior Researcher

---

From: Marco Tiloca <[email-masked]>
Date: Tue, 25 Feb 2020 11:04:49 +0000

Hi Jim,

> [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.   I…

==>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

-- 
Marco Tiloca
Ph.D., Senior Researcher