On 22/10/2018 21:09, Jim Schaad wrote:
* Registries - I am wondering if we should think about re-writing a couple of the registries. As things stand it appears that the application/ace+cbor content type is being used in 5 or 6 places. It might make more sense to have a registry for all of the CBOR abbreviations that are being used in a single table and have multiple columns for each of the different places were the content format is being used. This would make it easier to keep everything constant and can make re-use of integer values easier to see.
Yes in the light of the ensuing discussion with Mike, Carsten and Olaf it is clear that the whole registry process needs a second (third, n-th) go-over.
I'd very much like to have all abbreviations in a single table, however some of them are in the new draft-ietf-ace-oauth-params, so I'm not sure on where to do the table, since I'd like to have the parameters from there in it.
* Comments on protection of CWT/Token: I am wondering if there needs to be any comments on how a CWT is going to be protected. While it is ok to use either a symmetric key or a direct key agreement operation for a single recipient without forcing a signature operation to occur. If the token is going to be targeted a single audience hosted on multiple RSs then a signature operation would be required for the purposes of authentication.
In the light of your and Steffi's comments, this seems to merit a section in the security considerations.
* I am not sure where this issue should be raised so I am putting it here. Both of the profiles have as their last security consideration a statement that the use of multiple access tokens is a bad idea. Both of them also devote a large section of text to how to deal with multiple access tokens as does this document. More methods of having multiple access tokens seem to be coming down the path from the OAuth group. This appears to be a distinct contradiction within the set of documents that should be resolved.
I'd like to have the view of our OAuth experts here: How is OAuth typically used, when a client needs to get more permissions than initially granted? Is the old token invalidated and a new token issued, or is there something like "add-on" scopes in additional tokens?
Given the amount of trouble the handling of multiple tokens for one client-RS pair can raise, I'm not disinclined to forbid them or at least recommend against their use. However with audiences possibly addressing overlapping sets of RSs this might be more difficult than it looks.
/Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
