Given that we have already started doing interop work and were successful needing to address the number assignment issues does not seem to be a blocking problem. As long as all of the people doing the interop testing are agreed on what numbers should be there do not seem to be any issues in testing. The only problem would be if there was a decision to ship products before the assignments were finalized.
In terms of what size of items to use, this is going to be an interesting argument and one that needs to be finalized at some point. However, it would be just as easy to remove the sentence as to change the values so there are multiple ways of solving this issue. I don’t know that I agree that application-specific claim keys should be pushed all of the way up to 256, there is always going to be a trade off at this point in terms of what size of key to use vs how often it is believed that the key is going to be used. If we believe that a huge percentage of usage in the IoT world for CWT items is going to be for this type of authorization and we want to keep alignment to the extent possible then it still makes sense to use the 1 or 2 byte keys for this purpose. (Side node, it is normal to include all of the bytes encoded in the length so 256 would be a 3 byte value). This is a trade off that needs to be discussed, but is not currently blocking. Jim From: Ace <ace-boun...@ietf.org> On Behalf Of Mike Jones Sent: Tuesday, May 8, 2018 10:40 AM To: Ludwig Seitz <ludwig.se...@ri.se>; ace@ietf.org Subject: Re: [Ace] OAuth-Authz Interop Before any interop work is done, I suggest that it would be better to first address the significant CBOR number assignment issues I pointed out in my review on October 10, 2017 https://www.ietf.org/mail-archive/web/ace/current/msg02364.html, so that the interop is more likely to occur using number assignments that are less likely to change. I'm repeating the most important of these comments below, since it was apparently not acted upon. 5.5.5 Mapping parameters to CBOR It looks to me like these values are intended to align with those registered in the CBOR Web Token (CWT) Claims registry initially populated by https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#section-9.1.2. If so, the spec should make this relationship explicit. However, it would be inappropriate to use the rare single-byte CBOR integer values for application-specific claim keys. I would suggest that the claim identifiers for client_id through refresh_token and profile start at 256 (a two-byte CBOR value) and go up from there. In that case, I suspect they could be successfully registered in the CWT Claims registry – which I think you want. (“cnf” will already be registered by draft-ietf-ace-cwt-proof-of-possession.) Likewise, please search the review for all instances of the words “register” and “registry” and revised the spec accordingly before any interop work is started. -- Mike -----Original Message----- From: Ace <ace-boun...@ietf.org <mailto:ace-boun...@ietf.org> > On Behalf Of Ludwig Seitz Sent: Tuesday, May 8, 2018 3:54 AM To: ace@ietf.org <mailto:ace@ietf.org> Subject: Re: [Ace] OAuth-Authz Interop On 2018-05-08 08:57, Ludwig Seitz wrote: > On 2018-05-07 18:44, Jim Schaad wrote: >> I have been meaning to get this out for a while and have failed. A >> doodle poll to setup an interop event for this work is at >> <https://doodle.com/poll/k27g9r26bghvnytu> >> https://doodle.com/poll/k27g9r26bghvnytu If you want to participate >> and none of the times are good please let me know. >> >> Things for testing: >> 1) DTLS profile w/ shared secret >> 2) DTLS profile w/ RPK >> 3) OSCORE profile >> >> > > Note that I'm in the process of writing a test manual, I'll put it up > on the WG github as soon as it has some form and structure. Feel free > to contribute. I'm hoping to have it online by the end of the day. > > /Ludwig > > You can find my first draft of the interop manual here: <https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt> https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt Note that large parts are still work in progress, but the test plan for the token endpoint should give you a hint as to how I was thinking it could work. Feel free to propose changes and improvements. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list <mailto:Ace@ietf.org> Ace@ietf.org <https://www.ietf.org/mailman/listinfo/ace> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
