Hi Mike, The group key is also the authorization key in the model proposed. Any entity that holds that key can forge a message that can cause the action authorized by the issuance of that key. In your example, assuming that the door lock and the lightbulb share the same group key, then compromising the lightbulb allows you to control the door lock. [AS] This is not the model we have in mind in the document. It is clear that the document needs some more specification work which relies on OSCOAP/COSE being complete. However, if you look at sections 3.3 and 3.4 both the AT-R and AT-KDC assume that there is a field "Scope" which mentions permissions of the entity holding the token including "which resources maybe accessed with the token". So, compromising a lightbulb group key does not automatically imply that the door-lock can be controlled with the same key.
In general, authentication comes with the key that you have - authorization is then tied to that key. In DTLS (as in TLS), your session key is also your authorization key once your TLS session is tied to a particular identity (e.g. via an HTTP login, via a client cert exchange, via OAuth). So - cosmetic differences only. Mike /Ludwig _______________________________________________ Ace mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ace ________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
