Francesca Palombini <francesca.palomb...@ericsson.com> wrote:
mcr> Is there an assumption that the access rights(T2) >= access
mcr> rights(T1)?
> FP: No. But at the same time if access rights(T2) is a subset of access
> rights(T1), then there is no point in the client requesting T2 from the
> AS... These could be a disjoint sets of access rights.
There are some cases here.
T2 is a superset of T1. Everything makes sense.
T2 is a subset of T1. I to think about this.
T2 is complete disjoint of T1.
T2 is the union of a subnet of T1, and some new set of rights T2B.
That is, partial overlap, but T2 not superset of T1.
> FP: As currently defined in the document, yes, Sec1 ends up being
> deleted as soon as Sec2 is validated (i.e. a request is correctly
> decrypted by the receiving endpoint using Sec2). If T1 and T2 do
> different things and the client wants to (and is allowed to - T1 is not
> expired or revoked for some reason) keep T1 alive, then we are not in
> the case of "update of access rights", i.e. the case where T2 replaces
> T1. My "Final point" was to cover exactly the case you mention, where
> T1 and T2 are used to derive 2 different security contexts, where the
> RS does not realize they come from the same Client. It is up to the AS
> to make sure that T1 and T2 are disjoints: why would the AS even send 2
> different tokens that cover part of or the entire same scope at the
> same RS to the same client? By the way, if it is not already in there,
> I think that that is another excellent consideration point for the Ace
> framework.
Client could be vaguely "multi-tenant", having a common security substrate.
That's why there could be 2 different tokens.
Think intelligent speakers that can learn "skills".
One skill operates the stereo, and wants to adjust living room lighting for
appropriate mood. (/me deletes off-colour joke about South Park)
The other skill is the sleep aid, and just wants to dim all lights to near
darkness, but should not operate stereo.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
