Hi, Ludwig. Yes, -08 addresses the two points noted below... unfortunately you didn't fix the various nits and the other minor issues as you indicated you were intending to in your initial response (EC => EC2, etc). Enjoy the holidays! Cheers, Elwyn Sent from Samsung tablet. -------- Original message -------- From: Ludwig Seitz <ludwig_seitz@xxxxxx> Date: 21/12/2019 12:22 (GMT+00:00) To: elwynd <elwynd@xxxxxxxxxxxx>, elwynd@xxxxxxxxxxxxxx Cc: last-call@xxxxxxxx, gen-art@xxxxxxxx, ace@xxxxxxxx Subject: Re: [Gen-art] [Ace] Genart last call review of
draft-ietf-ace-oauth-params-06 > Hi, Ludwig. > > Thanks for the prompt response. > > Regarding he major issue, I understand what the intention of the split > was, but as far as early implementations are concerned, there is no such > thing as a 'minimal breakage'; unless there is some cunning mechanism in > the basic ace-oauth-authz protocol, changes to the structure of the > items defined here will break the protocol. One possibility that I > could see is the addition of extra keys in the COSE_Key dictionary > structure: In this case you could add some extra words (in the > ace-oauth-authz document) to indicate that unrecognized keys should be > ignored. This is associated with the editorial comments I made about > s3.1 that would allow any other keys to be present in the COSE_Key > object structure. Similarly, the obects defined here are effectively > JSON/CBOR dictionaries. The changes could be accomodated by adding > comments in ace-oauth that extra keys in the items defined would be > ignored. > > In my opinion, it would be best to remove the comments about possible > changes and just state that they have been separated out because they > might be used in other contexts. The possible 'changes to the > definitions' issue is just a matter of 'institutional memory'. If there > is some mechanism, such as I mentioned above, to accommodate changes > without neeeding an update to the ace-oauth-authz (or other protocols > using these items), this should be explained. I have submitted an updated draft (-08) that removes the comments about possible changes. Does this address your major issue? > > Regarding the h vs b64 representations, since they are only examples > (and the strings are essentially arbitrary as the actual keys aren't in > the document), I'd be inclined to put in h representations to avoid my > question arisng. In my newly submitted draft all the b64 representations have been replaced by equivalent h representations. Note that none of these strings are arbitrary, since they do parse to actual keys. The abbreviated b64 strings representing tokens obviously do not parse as such, but come from the actual binary representation of tokens. Happy holidays, Ludwig |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
