Hi Jim, This sounds over-engineered to me.
If we go for introducing new claims (or putting requirements on existing ones like 'cti'), I would suggest to EITHER Use the solution recommended in the framework today: One token per pop-key, new token overwrites old token, adding a strict ordering, e.g. by requiring that the AS uses a incremented number in the cti claim (or a new claim if we don't want to use cti for that). This would introduce part of what Olaf suggested, i.e. a strict ordering. OR Go with Olaf's full suggestion and introduce a revocation mechanism. /Ludwig -----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Jim Schaad Sent: den 18 maj 2020 05:22 To: 'Francesca Palombini' <francesca.palomb...@ericsson.com> Cc: 'Ace Wg' <ace@ietf.org> Subject: Re: [Ace] Update of access rights I have not had a chance to think this out and get all of the implications right, but my understanding is that what we were trying to avoid was having the same secret key/public key present on the RS in more than one token. This simplifies what the RS needs to do. However, I am now under the impression that having the RS deal with multiple tokens with the same public key might be less of an issue than trying to make some decisions on what tokens are supposed to supersede other tokens. One of the ways that this might be avoided is to push the problem to where it, in some sense, belongs. The AS should be able to make this type of decision if a token is supposed to replace an existing token or not and it has more knowledge about what tokens are associated with what keys. If we go back and say - the AS should include a CWTID in the token and then define a new claim which says - This token supersedes the token(s) with CWTID values of "x", "y" and "z". Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
