Example: If you have a CWT authorizing A for audience Z and you now also
need authorization B for audience Z, you should request a CWT for A+B
for audience Z, that replaces your previous one.
Do I understand?
two possibilities:
A and B are members of audience Z; no new CWT needed
B is a new member of audience Z; then audience Z becomes audience
Z-prime and a new CWT seems reasonable.
Peter
Ludwig Seitz schreef op 2019-08-20 11:09:
> On 19/08/2019 22:40, Jim Schaad wrote:
>
>> As Ludwig pointed out during the F2F, it makes far more sense to try and
>> keep an entity using the same key identifier for as long as possible. This
>> is in part to make sure that signing keys do not need to be retrieved if
>> they can be easily cached. In looking at this deeper during my
>> implementation I ended up with the following question:
>>
>> The way that I have set things up in my implementation it is simple to
>> ensure that the same kid value is going to be used with the same CWT,
>> however it might make more sense to use the signing key as the continuity
>> identifier instead. The issue that arises in this case is that there might
>> be two different active CWT objects that are associated with the same
>> signing key. That is there are two CWTs but the same signing key was used
>> while doing a join operation. I already do some matching between different
>> CWTs by assuming that if the bearer key in the CWT is the same then they are
>> sufficiently equivalent to threat them as the same. This lead to some
>> interesting discussions in Montreal about if this meant just the "secret" or
>> if it meant all of the elements provided by the AS which are used in the key
>> derivation process. (I have gone back and forth on this and currently am
>> sitting on the "just the secret" side of the fence.)
>>
>> Does anyone have any opinions?
> Could you please expand the explanation of your use case a bit?
>
> Are you thinking of a scenario where someone would be using the
> counter-signature key from group-OSCORE as a proof-of-possession (pop) key in
> serveral CWTs?
>
> What would these CWT authorize?
>
> Why would an entity hold several CWTs for the same audience?
>
> Side-note:
> My stance on multiple CWTs linked to the same pop-key and for the same
> audience is that the latter one should supersede the previous ones.
> Example: If you have a CWT authorizing A for audience Z and you now also need
> authorization B for audience Z, you should request a CWT for A+B for audience
> Z, that replaces your previous one.
>
> /Ludwig
>
> _______________________________________________
> Ace mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
